Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 221)

decode_funding_addresses inserts each FFI row into a BTreeMap without checking key collisions, so if Swift submits two rows for the same PlatformAddress, the second silently overwrites the first. Two consequences: (a) the funded output set differs from what the caller's [FundingRecipient] ordering and remainderIndex (ManagedPlatformAddressWallet.swift:460-465, 558-563) describe, and (b) a duplicate that flips has_balance can re-designate which entry is the None remainder, changing fee-strategy targeting after deduplication.

Note: this same silent-insert pattern exists in the sibling parse_outputs (platform_address_types.rs:189-204) used by the transfer path and in the legacy fund_from_asset_lock.rs:35-44 decode loop — codex's claim that 'the transfer API already rejects duplicate recipients' is inaccurate. So this is a pre-existing FFI pattern rather than a new regression, but the new funding API is a good place to start tightening it: rejecting duplicates here protects callers from a class of confusing protocol-side failures.

pub(super) unsafe fn decode_funding_addresses(
    addresses: *const FundingAddressEntryFFI,
    addresses_count: usize,
) -> Result<BTreeMap<PlatformAddress, Option<dpp::fee::Credits>>, PlatformWalletFFIResult> {
    let mut address_map = BTreeMap::new();
    for entry in std::slice::from_raw_parts(addresses, addresses_count) {
        let addr = PlatformAddress::try_from(entry.address).map_err(|e| {
            PlatformWalletFFIResult::err(
                PlatformWalletFFIResultCode::ErrorInvalidParameter,
                format!("invalid platform address: {e}"),
            )
        })?;
        let balance = if entry.has_balance { Some(entry.balance) } else { None };
        if address_map.insert(addr, balance).is_some() {
            return Err(PlatformWalletFFIResult::err(
                PlatformWalletFFIResultCode::ErrorInvalidParameter,
                "duplicate platform address in funding recipients",
            ));
        }
    }
    Ok(address_map)
}

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 201)

After a successful submit, write_address_balances_changeset updates ManagedPlatformAccount in memory and returns a PlatformAddressChangeSet, but the orchestrator does not call self.persister.store(cs.clone().into()). The transfer path (transfer.rs:155-159) explicitly persists, with a long comment explaining that without persistence initialize_from_persisted on the next process start would seed stale balances and break auto_select_inputs.

The legacy fund_from_asset_lock (fund_from_asset_lock.rs:100-102) has the same gap, so this PR isn't introducing the divergence — it's preserving it on the new orchestrated path. Worth closing on both paths so the new user-facing fund-from-Core flow is crash-resumable without relying on the next BLAST sync to reconcile.

        if !cs.addresses.is_empty() {
            if let Err(e) = self.persister.store(cs.clone().into()) {
                tracing::error!("Failed to persist platform-address funding changeset: {}", e);
            }
        }

        Ok(cs)

packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/ManagedPlatformAddressWallet.swift (line 594)

FundingRecipient docs at :382 say 0 = P2PKH, 1 = P2SH, and both new entry points forward addressType unchanged into PlatformAddressFFI (:449, :551). On the Rust side, TryFrom<PlatformAddressFFI> for PlatformAddress at packages/rs-platform-wallet-ffi/src/platform_address_types.rs:40-42 only accepts 0 and returns Unsupported address type for anything else. The Rust orchestrator also explicitly enforces P2PKH-only (fund_with_funding.rs:336-339).

Swift callers will only learn this after crossing the FFI boundary and getting a generic invalid-parameter error. The preflight is the right place to surface it.

        for r in recipients {
            guard r.addressType == 0 else {
                throw PlatformWalletError.invalidParameter(
                    "FundingRecipient.addressType currently supports only 0 (P2PKH); got \(r.addressType)"
                )
            }
            guard r.hash.count == 20 else {
                throw PlatformWalletError.invalidParameter(
                    "FundingRecipient.hash must be exactly 20 bytes (got \(r.hash.count))"
                )
            }
        }

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 88)

submit_with_cl_height_retry has an explicit regression-pinning test (orchestration.rs:476), and the underlying DPP and SDK primitives are exercised in their crates. But the new orchestrator itself — which composes pre-flight + funding resolution + retry submission + IS→CL rejection fallback + balance writeback + asset-lock consume — has no direct test.

The most fragile branch is the IS-rejection fallback at lines 173-197: it restarts submit_with_cl_height_retry from the original settings (settings is Copy, so the bumped value from the first call is discarded). That is intentional (the proof type changes, so the ST hash differs and Tenderdash's invalid-tx cache no longer applies), but a follow-up refactor switching to &mut settings would silently break it. The PR description also marks end-to-end testnet validation as still pending. A targeted #[tokio::test] (e.g. with start_paused = true) covering (a) IS-timeout → CL upgrade, (b) IS-rejection → CL upgrade, (c) consume-on-success, would lock in the orchestration shape.

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 271)

write_address_balances_changeset finds address_index by walking account.addresses.addresses and matching by PlatformP2PKHAddress, falling back to 0 on miss. Pre-flight uses account.contains_platform_address(&p2pkh) — a different collection — so the two views can disagree if the address pool hasn't been hydrated for the given gap-limit slot, and the from_address(...).ok() silently swallows parse mismatches. The downstream effect is a PlatformAddressBalanceEntry attributing the funded balance to address_index = 0 while every other field is correct — exactly the kind of silent off-by-one a SwiftData persister or UI will surface as 'all my funds landed on address #0'.

The same pattern exists in transfer.rs:119-129 (preserved, not introduced), but the orchestrated funding path has more chances for divergence because the address may have just been auto-picked from the unused pool. Prefer tracing::warn! on the fallback or skip the changeset entry when the index can't be resolved.

packages/rs-platform-wallet/src/wallet/asset_lock/orchestration.rs (line 404)

The module declares CL_FALLBACK_TIMEOUT (180s), CL_HEIGHT_RETRY_DELAY (15s), and CL_HEIGHT_RETRY_BUDGET (210s) as policy knobs, and the module docs describe the IS-lock resume wait (300s) as policy too — but it's inlined as a bare literal in the FromExistingAssetLock branch. Promote to e.g. IS_LOCK_RESUME_TIMEOUT so a future tuning pass touches one site. Also note: fund_with_funding.rs:143 resumes with CL_FALLBACK_TIMEOUT (180s) for the same asset-lock manager wait, while the resolver here uses 300s — worth a comment if intentional or aligning if not.

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 210)

The comment on decode_funding_addresses claims it's 'Shared with the legacy raw-private-key [crate::platform_addresses::fund_from_asset_lock] FFI so both entry points agree on the wire shape.' In fact, platform_addresses/fund_from_asset_lock.rs:35-44 still inlines its own decode loop with for entry in std::slice::from_raw_parts(addresses, addresses_count) { let addr = unwrap_result_or_return!(...); }. The two paths are not actually sharing decoding logic, so a future tightening (e.g. duplicate rejection, P2SH boundary check, error-message wording) on one will silently diverge from the other. Either route the legacy FFI through decode_funding_addresses to make the comment true, or correct the comment.

packages/rs-platform-wallet/src/wallet/asset_lock/orchestration.rs (line 217)

submit_with_cl_height_retry treats a single InvalidAssetLockProofCoreChainHeightError from the connected DAPI node as authoritative and bumps PutSettings::user_fee_increase before resubmitting. With fund_addresses_with_funding now wrapping Core-funded address top-ups in this helper, a malicious or desynchronized node can drive up to ~CL_HEIGHT_RETRY_BUDGET / CL_HEIGHT_RETRY_DELAY retries with escalating fees per address-funding attempt without holding the asset-lock key.

Not a new vector in this PR — the identity-funding path uses the same helper — but worth tracking as a bounded griefing surface across a new trust boundary. A future hardening pass should consider second-source confirmation or node rotation before accepting a fee bump.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/FundPlatformAddressView.swift (line 309)

recipientCandidates requires both !$0.isUsed and $0.balance == 0. The Rust-side pre-flight in validate_recipient_addresses only requires that the address belong to the supplied platform-payment account — it does not require the address to be unused or empty. Users who have previously funded or received to a platform address cannot pick it again from this screen even though the protocol accepts it.

If the intent is to bias the default toward fresh addresses without forbidding used ones, prefer sorting (used last) over filtering them out, or split the filter from the auto-pick policy in autoSelectRecipient. If the intent is genuinely to forbid them, the UI should explain why.

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 218)

The safety doc says addresses must be non-null. Inside, it unconditionally calls std::slice::from_raw_parts(addresses, addresses_count) — which is UB on a null data pointer even when count == 0 (the function requires a non-null aligned dangling-or-valid pointer). Today's two callers both do check_ptr!(addresses) first, so it's sound. But because the helper is pub(super), a future caller in the same module that forgets the prelude is one keystroke from UB.

Sibling helpers in the same crate (parse_outputs, parse_explicit_inputs) defensively check if ptr.is_null() && count > 0 { ... } internally, but even that pattern isn't quite right for the count == 0 case. Adding if addresses.is_null() { return Err(...); } unconditionally aligns this helper with the rest of the crate without changing today's behavior.

• **[suggestion] packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/ManagedPlatformAddressWallet.swift:594 — Swift FundingRecipient advertises addressType=1 (P2SH) but Rust FFI rejects it

  Verified at ff31d50: the Swift FundingRecipient doc states 0 = P2PKH, 1 = P2SH, and both fundFromCoreAssetLock and resumeFundFromAssetLock forward addressType unchanged into PlatformAddressFFI. On the Rust side, TryFrom<PlatformAddressFFI> for PlatformAddress only accepts 0 and returns 'Unsupported address type' for anything else; the orchestrator additionally enforces P2PKH-only. fundFromCoreAssetLockPreflight (594-613) checks hash.count == 20 but does NOT check addressType == 0, so callers learn the constraint only after crossing the FFI boundary and getting a generic invalid-parameter error. The preflight is the right place to surface it — alternatively, narrow the Swift API surface (e.g. drop the byte and assume P2PKH) until P2SH is actually implemented on the Rust side.

• **[suggestion] packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs:221 — Duplicate funding recipients silently collapse in BTreeMap decode

  Verified at ff31d50 (lines 221-241 unchanged from c547c4d): decode_funding_addresses inserts each FFI row into a BTreeMap without checking key collisions. If Swift submits two rows for the same PlatformAddress, the second silently overwrites the first. Two consequences: (a) the funded output set diverges from the caller's [FundingRecipient] ordering and remainderIndex computation (Swift indexes the pre-collapse array at ManagedPlatformAddressWallet.swift:460-465, 558-563), and (b) a duplicate that flips has_balance can re-designate which entry is the None remainder, changing fee-strategy targeting. BTreeMap::insert's return value already detects the collision at zero extra cost.

• **[suggestion] packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs:205 — Funding success path doesn't push changeset through the persister

  Verified at ff31d50 (lines 205-223 unchanged from c547c4d): after a successful submit, write_address_balances_changeset mutates ManagedPlatformAccount in memory and returns a PlatformAddressChangeSet, but the orchestrator never calls self.persister.store(cs.clone().into()). The transfer path explicitly persists (with a comment about how initialize_from_persisted would otherwise seed stale balances and break auto_select_inputs on next process start). The legacy fund_from_asset_lock has the same gap, so this PR preserves rather than introduces the divergence — but closing it on the new path makes the user-facing fund-from-Core flow crash-resumable without relying on the next BLAST sync to reconcile. Alternatively, change the return type so the caller is forced to acknowledge the not-yet-persisted state.

• **[suggestion] packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs:88 — No direct tests for fund_addresses_with_funding orchestration branches

  Verified at ff31d50: submit_with_cl_height_retry has an explicit regression-pinning test and the underlying DPP/SDK primitives are exercised elsewhere, but the new orchestrator — composing pre-flight, funding resolution, retry submission, IS→CL rejection fallback, balance writeback, and asset-lock consume — has no direct test. The most fragile branch is the IS-rejection fallback at lines 173-197: it restarts submit_with_cl_height_retry from the original settings (settings is Copy, so the bumped value from the first call is discarded). That is intentional (the proof type changes, so the ST hash differs and Tenderdash's invalid-tx cache no longer applies), but a follow-up refactor switching to &mut settings would silently break it. A targeted #[tokio::test] (with start_paused = true) covering (a) IS-timeout → CL upgrade, (b) IS-rejection → CL upgrade, (c) consume-on-success, would lock in the orchestration shape. PR description marks end-to-end testnet validation as still pending.

• **[nitpick] packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs:210 — Doc claim of 'shared with the legacy raw-private-key FFI' is inaccurate

  Verified at ff31d50: the comment on decode_funding_addresses claims it's 'Shared with the legacy raw-private-key [crate::platform_addresses::fund_from_asset_lock] FFI so both entry points agree on the wire shape.' In fact, platform_addresses/fund_from_asset_lock.rs:35-44 still inlines its own decode loop. The two paths are not actually sharing decoding logic, so a future tightening (duplicate rejection, P2SH boundary check, error-message wording) on one will silently diverge from the other. Either route the legacy FFI through decode_funding_addresses to make the comment true, or correct the comment.

• **[nitpick] packages/rs-platform-wallet/src/wallet/asset_lock/orchestration.rs:402 — Inline Duration::from_secs(300) should join the other named timeout constants

  Verified at ff31d50: the module declares CL_FALLBACK_TIMEOUT (180s), CL_HEIGHT_RETRY_DELAY (15s), and CL_HEIGHT_RETRY_BUDGET (210s) as named policy knobs, and the module docs describe the IS-lock resume wait (300s) as policy too — but it's inlined as a bare literal in the FromExistingAssetLock branch at line 404. Promote to e.g. IS_LOCK_RESUME_TIMEOUT. Also: fund_with_funding.rs:143 resumes with CL_FALLBACK_TIMEOUT (180s) for the same asset-lock manager wait, while the resolver here uses 300s — worth a comment if intentional or aligning if not.

• **[nitpick] packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs:271 — Silent unwrap_or(0) for address_index in funding changeset writeback

  Verified at ff31d50: write_address_balances_changeset resolves address_index by walking account.addresses.addresses and matching by PlatformP2PKHAddress, falling back to 0 with unwrap_or(0) on miss. Pre-flight uses account.contains_platform_address(&p2pkh) — a different collection — so the two views can disagree if the address pool hasn't been hydrated for the given gap-limit slot, and from_address(...).ok() silently swallows parse mismatches. The downstream effect is a PlatformAddressBalanceEntry attributing the funded balance to address_index = 0 while every other field is correct — exactly the kind of silent off-by-one a SwiftData persister will surface as 'all my funds landed on address #0'. The same pattern exists in transfer.rs:119-129 (preserved, not introduced). Prefer tracing::warn! on the fallback, or skip the changeset entry when the index can't be resolved.

• **[nitpick] packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/FundPlatformAddressView.swift:309 — Recipient picker over-restricts to !isUsed && balance == 0

  Verified at ff31d50 (line 312 unchanged — the latest delta refactored only WalletDetailView, not FundPlatformAddressView): recipientCandidates requires both !$0.isUsed and $0.balance == 0. The Rust-side pre-flight in validate_recipient_addresses only requires that the address belong to the supplied platform-payment account — it does not require the address to be unused or empty. Users who have previously funded or received to a platform address cannot pick it again from this screen even though the protocol accepts it. If the intent is to bias the default toward fresh addresses, prefer sorting (used last) over filtering, or split the filter from the auto-pick policy in autoSelectRecipient. If the intent is genuinely to forbid them, the UI should explain why.

• **[nitpick] packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs:218 — decode_funding_addresses relies on caller's check_ptr! for null-safety

  Verified at ff31d50: the // Safety doc requires non-null addresses. Inside, it unconditionally calls std::slice::from_raw_parts(addresses, addresses_count) — which is UB on a null data pointer even when count == 0 per the slice contract. Today's two callers both do check_ptr!(addresses) first, so it's sound. But the helper is pub(super), and a future intra-module caller that forgets the prelude — or fast-paths addresses_count == 0 on the hunch that 'an empty array can't matter' — would silently introduce UB at an FFI trust boundary consuming attacker-controlled pointers. Sibling helpers (parse_outputs, parse_explicit_inputs) defensively null-check internally; aligning here costs nothing and removes a sharp edge from the boundary.

• **[nitpick] packages/rs-platform-wallet/src/wallet/asset_lock/orchestration.rs:217 — Single DAPI 10506 response can force fee escalation across new funding path

  Verified at ff31d50: submit_with_cl_height_retry treats a single InvalidAssetLockProofCoreChainHeightError from the connected DAPI node as authoritative and bumps PutSettings::user_fee_increase before resubmitting. With fund_addresses_with_funding now wrapping Core-funded address top-ups in this helper, a malicious or desynchronized node can drive up to ~CL_HEIGHT_RETRY_BUDGET / CL_HEIGHT_RETRY_DELAY retries with escalating fees per address-funding attempt without holding the asset-lock key. The trust model is now explicitly documented at orchestration.rs:217-234 (bounded budget, attack-unprofitability reasoning), so this is documented technical debt rather than an undisclosed defect — carrying forward for visibility. A future hardening pass should consider second-source confirmation or node rotation before accepting a fee bump.

packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/ManagedPlatformAddressWallet.swift (line 606)

Verified at 9889023: fundFromCoreAssetLockPreflight (594-613) validates hash.count == 20 but does not validate addressType. The public Swift FundingRecipient documents 0 = P2PKH, 1 = P2SH, and both fundFromCoreAssetLock and resumeFundFromAssetLock forward addressType unchanged into PlatformAddressFFI. On the Rust side, TryFrom<PlatformAddressFFI> for PlatformAddress only accepts 0 (packages/rs-platform-wallet-ffi/src/platform_address_types.rs:37-43) and the orchestrator additionally enforces P2PKH-only. A caller building a P2SH FundingRecipient therefore passes Swift preflight, crosses the FFI boundary, and surfaces only a generic invalid-parameter error from Rust. Surface this constraint in the preflight (or narrow the Swift API surface to drop the byte until P2SH is implemented on the Rust side).

        for r in recipients {
            guard r.addressType == 0 else {
                throw PlatformWalletError.invalidParameter(
                    "FundingRecipient.addressType currently supports only 0 (P2PKH); got \(r.addressType)"
                )
            }
            guard r.hash.count == 20 else {
                throw PlatformWalletError.invalidParameter(
                    "FundingRecipient.hash must be exactly 20 bytes (got \(r.hash.count))"
                )
            }
        }

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 221)

Verified at 9889023 (line 238): decode_funding_addresses calls address_map.insert(addr, balance) without inspecting the return value, so two FFI rows for the same PlatformAddress silently overwrite each other. Two concrete consequences across the boundary: (a) the funded output set the Rust orchestrator executes diverges from the ordered [FundingRecipient] array the Swift caller passed in — which is significant because Swift derives the remainder index from that pre-collapse array (ManagedPlatformAddressWallet.swift:460-465, 558-563); and (b) if the duplicate row flips has_balance, the lone None remainder target can shift, changing fee-strategy attribution silently after dedup. BTreeMap::insert's return already exposes the collision at zero cost — reject explicitly at the FFI boundary.

pub(super) unsafe fn decode_funding_addresses(
    addresses: *const FundingAddressEntryFFI,
    addresses_count: usize,
) -> Result<BTreeMap<PlatformAddress, Option<dpp::fee::Credits>>, PlatformWalletFFIResult> {
    if addresses.is_null() {
        return Err(PlatformWalletFFIResult::err(
            PlatformWalletFFIResultCode::ErrorInvalidParameter,
            "addresses pointer is null",
        ));
    }
    let mut address_map = BTreeMap::new();
    for entry in std::slice::from_raw_parts(addresses, addresses_count) {
        let addr = PlatformAddress::try_from(entry.address).map_err(|e| {
            PlatformWalletFFIResult::err(
                PlatformWalletFFIResultCode::ErrorInvalidParameter,
                format!("invalid platform address: {e}"),
            )
        })?;
        let balance = if entry.has_balance { Some(entry.balance) } else { None };
        if address_map.insert(addr, balance).is_some() {
            return Err(PlatformWalletFFIResult::err(
                PlatformWalletFFIResultCode::ErrorInvalidParameter,
                "duplicate platform address in funding recipients",
            ));
        }
    }
    Ok(address_map)
}

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 205)

Verified at 9889023 (lines 205-223): after a successful submit, write_address_balances_changeset mutates ManagedPlatformAccount and returns a PlatformAddressChangeSet, but the orchestrator returns immediately after consume_asset_lock without invoking self.persister.store(cs.clone().into()). The transfer path explicitly persists, with an inline comment that stale persisted balances would otherwise break initialize_from_persisted and auto_select_inputs on next process start. The Rust crate owns the persister, so the Swift caller cannot compensate from the returned changeset. The legacy fund_from_asset_lock has the same gap, so this is preserved rather than introduced — but the new Core-funded user-facing path stays crash-fragile until a sync reconciles. Note the relevance to the new delta in this PR: the Swift app now reads Core balances live from accountBalances(for:) instead of stale SwiftData precisely to dodge the same lag — the Platform side has an exact mirror here.

        let cs = self
            .write_address_balances_changeset(platform_account_index, &address_infos)
            .await;

        if !cs.addresses.is_empty() {
            if let Err(e) = self.persister.store(cs.clone().into()) {
                tracing::error!("Failed to persist platform-address funding changeset: {}", e);
            }
        }

        if let Some(out_point) = tracked_out_point {
            // Cleanup failure can only mean WalletNotFound (the wallet
            // handle that just funded the addresses vanished). Surface
            // as a warn — Platform DID accept the top-up, so
            // propagating the error to the caller would be misleading.
            if let Err(e) = self.asset_locks.consume_asset_lock(&out_point).await {
                tracing::warn!(
                    outpoint = %out_point,
                    error = %e,
                    "consume_asset_lock failed after successful Platform submit"
                );
            }
        }

        Ok(cs)

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 88)

Verified at 9889023: submit_with_cl_height_retry has an explicit regression-pinning test and DPP/SDK primitives are exercised elsewhere, but the new orchestrator composing preflight, funding resolution, IS→CL timeout fallback, IS-rejection fallback, retry submission, balance writeback, and asset-lock consume has no direct test. The most fragile branch is the IS-rejection fallback: it intentionally restarts submit_with_cl_height_retry from the original settings value (settings is Copy, so the bumped value from the first call is discarded) because the proof type changes and the ST hash differs, so Tenderdash's invalid-tx cache no longer applies. A future refactor switching to &mut settings would silently break that. A targeted #[tokio::test] (with start_paused = true) covering (a) IS-timeout → CL upgrade, (b) IS-rejection → CL upgrade, (c) consume-on-success would pin the orchestration shape. PR description marks end-to-end testnet validation as still pending.

packages/rs-platform-wallet/src/wallet/asset_lock/orchestration.rs (line 402)

Verified at 9889023 (line 404 confirmed): the module declares CL_FALLBACK_TIMEOUT (180s), CL_HEIGHT_RETRY_DELAY (15s), and CL_HEIGHT_RETRY_BUDGET (210s) as named policy knobs, and the module docs describe the IS-lock resume wait (300s) as policy too — but it's inlined as a bare literal in the FromExistingAssetLock branch. Additionally, fund_with_funding.rs resumes with CL_FALLBACK_TIMEOUT (180s) for the same asset-lock manager wait while the resolver here uses 300s; if intentional, add a comment, otherwise align. The mismatch matters because both timeouts gate when the FFI top_up call returns to Swift. Promote to e.g. IS_LOCK_RESUME_TIMEOUT.

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 210)

Verified at 9889023 (lines 214-216): the doc on decode_funding_addresses states it is 'Shared with the legacy raw-private-key [crate::platform_addresses::fund_from_asset_lock] FFI so both entry points agree on the wire shape.' That is not true — platform_addresses/fund_from_asset_lock.rs keeps its own inline for entry in from_raw_parts(...) decode loop. The two FFI decode paths therefore do not share logic, so any future tightening of one (duplicate rejection, null handling, P2SH boundary check, error wording) will silently diverge. Either route the legacy FFI through decode_funding_addresses to make the comment true, or correct the comment.

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 271)

Verified at 9889023 (lines 271-281): write_address_balances_changeset resolves address_index by walking account.addresses.addresses, parsing each stored address, matching by PlatformP2PKHAddress, and falling back to 0 via unwrap_or(0) on miss. Preflight membership uses account.contains_platform_address(&p2pkh) — a different collection — so the two views can disagree if the address pool is not hydrated for the relevant gap-limit slot, and the from_address(...).ok() swallows parse mismatches. The downstream effect is a PlatformAddressBalanceEntry with correct hash/balance but wrong address_index, which a SwiftData persister will surface as 'all my funds landed on address #0'. Same pattern exists in transfer.rs:119-129 (preserved, not introduced). Either tracing::warn! and skip the entry, or surface the invariant violation explicitly.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/FundPlatformAddressView.swift (line 317)

Verified at 9889023 (line 320): recipientCandidates requires !$0.isUsed && $0.balance == 0. The Rust-side preflight in validate_recipient_addresses only requires the address to belong to the supplied platform-payment account — it does not require unused or zero-balance. As a result, users cannot pick previously-funded or previously-received-on platform addresses from this screen even though the protocol and FFI accept them. If the intent is to bias the default toward fresh addresses, sort (used last) rather than filter, or split the filter from the auto-pick policy in autoSelectRecipient. If the intent is genuinely to forbid them, the UI should explain why.

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 218)

Verified at 9889023: the // Safety doc requires non-null addresses, but the body unconditionally calls std::slice::from_raw_parts(addresses, addresses_count). Per the slice contract this is UB on a null data pointer even when count == 0. Today's two FFI entry points gate with check_ptr!(addresses), so current call sites are sound. But the helper is pub(super) and sits on a C ABI trust boundary consuming caller-supplied raw pointers; a future intra-module caller that omits check_ptr! (or fast-paths addresses_count == 0 on the hunch that 'empty can't matter') would silently introduce UB the optimizer is free to compile into a memory-safety bug. Sibling helpers in this crate (parse_outputs, parse_explicit_inputs) defensively null-check internally; aligning here costs nothing.

pub(super) unsafe fn decode_funding_addresses(
    addresses: *const FundingAddressEntryFFI,
    addresses_count: usize,
) -> Result<BTreeMap<PlatformAddress, Option<dpp::fee::Credits>>, PlatformWalletFFIResult> {
    if addresses.is_null() {
        return Err(PlatformWalletFFIResult::err(
            PlatformWalletFFIResultCode::ErrorInvalidParameter,
            "addresses pointer is null",
        ));
    }
    let mut address_map = BTreeMap::new();
    for entry in std::slice::from_raw_parts(addresses, addresses_count) {
        let addr = PlatformAddress::try_from(entry.address).map_err(|e| {
            PlatformWalletFFIResult::err(
                PlatformWalletFFIResultCode::ErrorInvalidParameter,
                format!("invalid platform address: {e}"),
            )
        })?;
        let balance = if entry.has_balance { Some(entry.balance) } else { None };
        address_map.insert(addr, balance);
    }
    Ok(address_map)
}

packages/rs-platform-wallet/src/wallet/asset_lock/orchestration.rs (line 217)

Verified at 9889023: submit_with_cl_height_retry treats the first InvalidAssetLockProofCoreChainHeightError from the connected DAPI node as authoritative and bumps PutSettings::user_fee_increase before resubmitting, with up to roughly CL_HEIGHT_RETRY_BUDGET / CL_HEIGHT_RETRY_DELAY (~14) escalating retries. This PR extends the helper to wrap fund_addresses_with_funding, so a malicious or desynchronized DAPI node can now drive the same bounded fee-escalation grief on Core-funded platform-address top-ups in addition to identity registration. Attacker needs neither the asset-lock key nor Platform consensus control — just to be the queried endpoint. The trust model is explicitly documented in source (orchestration.rs:217-234) as accepted technical debt with a bounded-griefing/attack-unprofitability rationale, so this is carried forward for visibility rather than as an undisclosed defect. A future hardening pass should consider second-source confirmation or node rotation before accepting a fee bump.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/ManagedPlatformAddressWallet.swift (line 594)

Verified at 9efcf6e (lines 594-613): fundFromCoreAssetLockPreflight checks recipients.isEmpty, the single-nil-remainder invariant, and hash.count == 20, but never inspects addressType. Both fundFromCoreAssetLock and resumeFundFromAssetLock forward addressType unchanged into PlatformAddressFFI. On the Rust side, TryFrom<PlatformAddressFFI> for PlatformAddress (packages/rs-platform-wallet-ffi/src/platform_address_types.rs:37-43) only accepts 0, and the orchestrator additionally enforces P2PKH-only. A caller building a P2SH FundingRecipient therefore passes the synchronous preflight, spins up the Task, marshals the handle, and surfaces only a generic invalid-parameter error from Rust — defeating the entire point of the preflight, which the doc says exists to deliver a synchronous error before paying for the Task detach + handle marshaling. Either validate addressType == 0 in the preflight, or drop the byte from the public Swift surface until P2SH is actually wired up Rust-side.

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 221)

Verified at 9efcf6e (line 238): decode_funding_addresses calls address_map.insert(addr, balance) and ignores the return value, so two FFI rows for the same PlatformAddress silently overwrite each other at the C ABI boundary. Two concrete consequences: (a) the funded output set the Rust orchestrator executes diverges from the ordered [FundingRecipient] array the Swift caller built — Swift derives the remainder index from that pre-collapse array, so after dedup the Rust side may see a different recipient set and a different None remainder target than the fee strategy was computed against; (b) if the duplicate row flips has_balance, the lone None remainder target can shift, redirecting fees and remainder credits silently. BTreeMap::insert's return value already exposes the collision at zero cost — reject explicitly at the boundary so the input shape the caller passed is the input shape the orchestrator executes.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/AddressFundingProgressView.swift (line 51)

New at 9efcf6e. AddressFundingProgressSection.init constructs _activeLocks with a #Predicate scoped only by walletId == walletId && fundingTypeRaw == 4, sorted by updatedAt desc. The body then unconditionally drives currentStep, broadcastSubStep, and isInChainLockFallback from activeLocks.first (lines 109-127, 145-149, 154-163). AddressFundingController is keyed (walletId, platformAccountIndex, recipientHash) precisely to allow many concurrent fundings on one wallet (per its own doc), but PersistentAssetLock carries no recipient-hash linkage — only outPointHex, walletId, fundingTypeRaw, statusRaw, updatedAt. So when two AssetLockAddressTopUp flows are in flight, both progress views observe the same activeLocks query and both pick whichever lock most recently transitioned updatedAt. The identity-side analog disambiguates via identityIndexRaw; this view has no equivalent. Concrete consequence: Funding A's UI can advance to Step 3 because Funding B's lock just transitioned to Broadcast, even though A is still building its asset-lock tx. The controller's per-attempt .phase keeps .completed/.failed correct, but step count and CL-fallback footer can mis-attribute. Single-funding usage is unaffected; close this before the planned 'Pending Platform Funding' surface ships. Options: (a) return the asset-lock outpoint from the FFI on creation so the controller can scope its own @Query, or (b) add a recipient-hash field to PersistentAssetLock populated when the orchestrator picks the credit-output destination.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/FundPlatformAddressView.swift (line 59)

Verified at 9efcf6e: activeController is held only as @State local to this view (line 64) and never rehydrated from walletManager.addressFundingCoordinator on appear. The sheet is still presented via a plain .sheet from WalletDetailView, and .onAppear(perform: autoSelectDefaults) only resets defaults. So the user can dismiss the sheet interactively (Cancel is disabled while .inFlight, but swipe-down/interactive dismissal on iOS is not), and on re-presentation the view starts from activeController == nil and renders the blank form — the only way back to the original controller is to manually recreate the same slot and re-submit. That directly undercuts the in-source comment (lines 59-64) that lifetime ownership lives on the coordinator so 'view dismissal mid-flight doesn't lose the work'. Either rehydrate from the coordinator in .onAppear keyed by (walletId, platformAccountIndex, recipientHash), or block interactive dismissal while in-flight.

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 205)

Verified at 9efcf6e (lines 205-223): after a successful submit, write_address_balances_changeset mutates ManagedPlatformAccount and returns a PlatformAddressChangeSet, but the orchestrator returns immediately after consume_asset_lock without invoking self.persister.store(cs.clone().into()). The transfer path explicitly persists with an inline comment that stale persisted balances would otherwise break initialize_from_persisted and auto_select_inputs on next process start. The Rust crate owns the persister, so the Swift caller cannot compensate from the returned changeset. A crash between consume_asset_lock and the next BLAST sync leaves a window where Platform has accepted the top-up but the local wallet doesn't know — affecting auto-input selection and any UI reading balances from the persisted SwiftData store. The legacy fund_from_asset_lock has the same gap (preserved, not introduced). Notable: the new AddressFundingCoordinator keeps the controller alive across view dismissal precisely so the success transition is observable — that's negated for a process restart while the persister gap remains.

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 88)

Verified at 9efcf6e: submit_with_cl_height_retry has an explicit regression-pinning test and DPP/SDK primitives are exercised elsewhere, but the new orchestrator composing preflight, funding resolution, IS→CL timeout fallback, IS-rejection fallback, retry submission, balance writeback, and asset-lock consume has no direct test. The most fragile branch is the IS-rejection fallback: it intentionally restarts submit_with_cl_height_retry from the original settings value — because PutSettings is Copy, the bumped value from the first call is discarded, which is required because the proof type changes, the ST hash differs, and Tenderdash's invalid-tx cache no longer applies. A future refactor switching to &mut settings would silently break that retry-cache-bypass invariant. A targeted #[tokio::test] (with start_paused = true) covering (a) IS-timeout → CL upgrade, (b) IS-rejection → CL upgrade, and (c) consume-on-success would pin the orchestration shape. PR description marks end-to-end testnet validation as still pending.

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 210)

Verified at 9efcf6e (lines 214-216): the doc on decode_funding_addresses states it is 'Shared with the legacy raw-private-key [crate::platform_addresses::fund_from_asset_lock] FFI so both entry points agree on the wire shape.' Confirmed false — platform_addresses/fund_from_asset_lock.rs:35-44 still has its own inline for entry in from_raw_parts(...) decode loop. The two FFI decode paths therefore do not share logic, so any future tightening of one (duplicate rejection, null handling, P2SH boundary check, error wording) will silently diverge across the boundary. Either route the legacy FFI through decode_funding_addresses to make the comment true, or correct the comment.

packages/rs-platform-wallet/src/wallet/asset_lock/orchestration.rs (line 402)

Verified at 9efcf6e (line 404): the module declares CL_FALLBACK_TIMEOUT (180s), CL_HEIGHT_RETRY_DELAY (15s), and CL_HEIGHT_RETRY_BUDGET (210s) as named policy knobs, and the module docs describe the IS-lock resume wait (300s) as policy too — but it's inlined as a bare literal in the FromExistingAssetLock branch. Separately, fund_with_funding.rs resumes with CL_FALLBACK_TIMEOUT (180s) for the same asset-lock manager wait while the resolver here uses 300s; if intentional, document why, otherwise align. Both timeouts gate when the FFI top_up call returns to Swift — and the new AddressFundingProgressSection.instantLockTimeout = 300.0 is yet another mirror that will drift independently from the Rust side. Promote to e.g. IS_LOCK_RESUME_TIMEOUT and reconcile the three sites.

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 218)

Verified at 9efcf6e: the // Safety doc requires non-null addresses, but the body unconditionally calls std::slice::from_raw_parts(addresses, addresses_count). Per the slice contract this is UB on a null data pointer even when count == 0. Today's two FFI entry points gate with check_ptr!(addresses) before the call, so current call sites are sound. But the helper is pub(super) and sits on a C ABI trust boundary consuming caller-supplied raw pointers; a future intra-module caller that omits check_ptr! — or fast-paths addresses_count == 0 on the hunch that 'empty can't matter' — would silently introduce UB the optimizer is free to compile into a memory-safety bug. Sibling helpers in this crate defensively null-check internally; aligning here costs nothing and removes a sharp edge from a security boundary.

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 271)

Verified at 9efcf6e (lines 271-281): write_address_balances_changeset resolves address_index by walking account.addresses.addresses, parsing each stored address via PlatformP2PKHAddress::from_address(...).ok(), matching by PlatformP2PKHAddress, and falling back to 0 via unwrap_or(0) on miss. Preflight membership uses account.contains_platform_address(&p2pkh) — a different collection — so the two views can disagree if the address pool is not hydrated for the relevant gap-limit slot, and the .ok() swallows parse mismatches. The downstream effect is a PlatformAddressBalanceEntry with correct hash/balance but wrong address_index, which a SwiftData persister will surface as 'all my funds landed on address #0'. If a downstream operation ever derives signing keys or HD paths from address_index without re-matching the hash, the silent fabrication becomes a key-derivation mismatch. Same pattern exists in transfer.rs:119-129 (preserved, not introduced). Either tracing::warn! and skip the entry, or surface the invariant violation explicitly.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/FundPlatformAddressView.swift (line 320)

Still valid at 9efcf6e2: recipientCandidates continues to filter candidate platform addresses with !$0.isUsed && $0.balance == 0, while the Rust-side validate_recipient_addresses path only requires that the address belong to the supplied platform-payment account. That keeps the example UI narrower than the wallet orchestration actually supports, so users cannot pick some valid addresses through the demo flow.

packages/rs-platform-wallet/src/wallet/asset_lock/orchestration.rs (lines 217-297)

Still valid at 9efcf6e2: submit_with_cl_height_retry still treats the first InvalidAssetLockProofCoreChainHeightError response from the connected DAPI node as authoritative enough to increase PutSettings::user_fee_increase before resubmitting. This remains an accepted technical-debt/security-surface nitpick rather than a blocker, but it is still part of the cumulative finding set for this head.

packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/ManagedPlatformAddressWallet.swift (line 594)

Verified at 06c1930 (lines 594-613, unchanged from 9efcf6e): fundFromCoreAssetLockPreflight validates recipients.isEmpty, the single-nil-remainder invariant, and hash.count == 20, but never inspects addressType. Both fundFromCoreAssetLock and resumeFundFromAssetLock forward addressType unchanged into PlatformAddressFFI. On the Rust side, TryFrom<PlatformAddressFFI> for PlatformAddress only accepts 0 and the orchestrator additionally enforces P2PKH-only at validate_recipient_addresses. A caller building a P2SH FundingRecipient therefore passes the synchronous preflight, spins up the Task, marshals the handle, and only then surfaces a generic invalid-parameter error from Rust — defeating the documented purpose of the preflight (deliver a synchronous error before paying for the Task detach). This is also load-bearing for this PR's new backfillRecipientOnConsumedLock, which also hardcodes type=0 — both surfaces would need to be extended in lockstep if P2SH is ever wired up. Either reject addressType != 0 in the preflight, or drop the byte from the public Swift surface until Rust supports it.

        for r in recipients {
            guard r.addressType == 0 else {
                throw PlatformWalletError.invalidParameter(
                    "FundingRecipient.addressType currently supports only 0 (P2PKH); got \(r.addressType)"
                )
            }
            guard r.hash.count == 20 else {
                throw PlatformWalletError.invalidParameter(
                    "FundingRecipient.hash must be exactly 20 bytes (got \(r.hash.count))"
                )
            }
        }

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 221)

Verified at 06c1930: line 238 calls address_map.insert(addr, balance) and discards the return value, so two FFI rows for the same PlatformAddress silently overwrite each other at the C ABI boundary. Two concrete consequences: (a) the funded output set the Rust orchestrator executes diverges from the ordered [FundingRecipient] array the Swift caller built — Swift derives the remainder index from that pre-collapse array (ManagedPlatformAddressWallet.swift:460-465, 558-563), so after dedup Rust may see a different recipient set and a different None remainder target than the fee strategy was computed against; (b) if the duplicate row flips has_balance, the lone None remainder target can shift, redirecting fees and remainder credits silently. BTreeMap::insert's return value already exposes the collision at zero cost — reject explicitly at the boundary so the input shape the caller passed is the input shape the orchestrator executes.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/AddressFundingProgressView.swift (line 51)

Verified at 06c1930 (lines 60-66 unchanged): AddressFundingProgressSection.init builds _activeLocks with a #Predicate scoped only by walletId == walletId && fundingTypeRaw == 4, sorted by updatedAt desc, and the body drives currentStep, broadcastSubStep, and isInChainLockFallback from activeLocks.first (109-127, 145-149, 154-163). AddressFundingController is keyed (walletId, platformAccountIndex, recipientHash) precisely to allow many concurrent fundings on one wallet, but PersistentAssetLock carries no recipient-hash linkage during the in-flight phase — only outPointHex, walletId, fundingTypeRaw, statusRaw, updatedAt. The new recipientPlatformAddressHash column added in this PR is populated only after Consumed (statusRaw == 4), so it doesn't disambiguate during statusRaw ∈ [0,3]. Concrete consequence: Funding A's UI can advance to Step 3 because Funding B's lock just transitioned to Broadcast. The new PendingPlatformFundingsList explicitly invites concurrent fundings to coexist on one wallet, so this matters more than before. Fix: (a) propagate the asset-lock outpoint into AddressFundingController so the predicate can scope by outpoint, or (b) populate recipientPlatformAddressHash on the row at broadcast time, not just at consume.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/StorageRecordDetailViews.swift (line 2012)

New at 06c1930. Verified at lines 2015-2021: networkHRP() unconditionally returns "tdash" with an inline comment that 'Wallet row lookup is best-effort; we keep the explorer self-contained here.' The Rust canonical encoder (packages/rs-dpp/src/address_funds/platform_address.rs) picks the HRP from hrp_for_network(network) — dash on mainnet, tdash on testnet/devnet/regtest. Consequence: on mainnet the storage explorer renders funded platform-address rows as tdash1q…. A user copying that string back through any Rust-owned tool (CLI, SDK) gets rejected by PlatformAddress::from_bech32m_string because the HRP doesn't match the network — the round-trip Swift↔Rust silently breaks at the explorer boundary, which is exactly the surface users open to audit a funding when something looks wrong. record.walletId is already on the row; a FetchDescriptor<PersistentWallet>(predicate: walletId == record.walletId) lookup at render time would surface the network. Better still per the Swift SDK CLAUDE.md rule ('No re-implementing protocol constants … as Swift mirrors'), expose a single FFI helper that calls to_bech32m_string and returns the string for display, since the entire bech32mEncode/convertBits/type-byte mapping is a hand-rolled Swift mirror of canonical Rust logic with no round-trip test pinning them.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/FundPlatformAddressView.swift (line 629)

New at 06c1930. Verified at lines 629-665. Two distinct gaps in the same routine: (1) Line 640 hardcodes let recipientType: UInt8 = 0 // P2PKH discriminant., but the originally-FFI-submitted addressType byte (the thing this back-fill exists to document) is never captured on the controller. Today benign because the FFI rejects type != 0, but the moment either side relaxes (Swift preflight or Rust FFI) the storage explorer will display a wrong type discriminant for a successful funding. (2) Lines 641-649 match solely on (walletId, fundingTypeRaw==4, statusRaw==4, recipientPlatformAddressHash==nil) newest-first. With two back-to-back fundings on the same wallet, persister-callback ordering (Rust-side background actor) and SwiftUI .onChange ordering (MainActor continuation) are independent — Funding A's lock can reach Consumed first while Funding B's controller publishes .completed to SwiftUI first, stamping A's lock with B's recipient hash, and vice versa on A's later .completed. The in-source comment ('FIFO by completion time') asserts an invariant the runtime doesn't actually guarantee, and a single misordered match permanently mis-attributes both rows (the back-fill never reconsiders an already-stamped row). The downstream impact is the storage explorer's audit trail showing fundings going to addresses they didn't go to. Fix at the source: have Rust return the consumed outpoint(s) on the FFI changeset (the orchestrator already has tracked_out_point at fund_with_funding.rs:209), then back-stamp by outpoint instead of by status. Stash recipient.addressType on AddressFundingController while you're there.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/PendingPlatformFundingsList.swift (line 45)

New at 06c1930. Verified at lines 45-58: the construction of the exclusion set for resumableLocks is gated by inFlight.compactMap { _ in nil } — every entry returns nil, so the set is always empty. The inline comment acknowledges this ('The de-dupe set therefore never has entries today'). The SwiftData status filter (statusRaw ∈ [1,3]) excludes Consumed locks, but for an in-flight controller whose asset lock has just been broadcast, the same outpoint sits in status 2/3 long enough to render in the orphan list while its driving controller is concurrently in the in-flight list. Tapping Resume opens FundPlatformAddressView in resume mode against the same outpoint and the user can pick a different recipient than the original in-flight flow chose; the coordinator's single-flight gate (keyed on (walletId, platformAccountIndex, recipientHash)) doesn't catch it because the recipient hash differs. Two concurrent FFI calls then race against the same asset-lock outpoint. Bounded — Platform's asset-lock-consumption check rejects the second top_up ST so no double-credit — but the user pays full FFI roundtrip cost on a guaranteed-to-fail submission, and the failure surfaces as a generic Platform reject which masks the duplicate-attempt cause. Fix per the comment's own roadmap: have the controller expose its asset-lock outpoint once broadcast and feed it into the exclusion set.

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 205)

Verified at 06c1930 (lines 205-223 unchanged): after a successful submit, write_address_balances_changeset mutates ManagedPlatformAccount and returns a PlatformAddressChangeSet, but the orchestrator returns immediately after consume_asset_lock without invoking self.persister.store(cs.clone().into()). The transfer path explicitly persists with an inline comment that stale persisted balances would otherwise break initialize_from_persisted and auto_select_inputs on next process start. The Rust crate owns the persister, so the Swift caller cannot compensate from the returned changeset. A crash between consume_asset_lock and the next BLAST sync leaves a window where Platform has accepted the top-up but the local wallet doesn't know — affecting auto-input selection and any UI reading balances from the persisted SwiftData store. The new resumable-orphan surface in this PR doesn't help here: by the time we reach this code path the lock is already consumed, so there's nothing to resume — only the new credit balance is lost from persistence.

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 88)

Verified at 06c1930: submit_with_cl_height_retry has an explicit regression-pinning test and DPP/SDK primitives are exercised elsewhere, but the new orchestrator composing preflight, funding resolution, IS→CL timeout fallback, IS-rejection fallback, retry submission, balance writeback, and asset-lock consume has no direct test. The most fragile branch is the IS-rejection fallback: it intentionally restarts submit_with_cl_height_retry from the original settings value — because PutSettings is Copy, the bumped value from the first call is discarded, which is required because the proof type changes, the ST hash differs, and Tenderdash's invalid-tx cache no longer applies. A future refactor switching to &mut settings would silently break that retry-cache-bypass invariant. A targeted #[tokio::test] (with start_paused = true) covering (a) IS-timeout → CL upgrade, (b) IS-rejection → CL upgrade, (c) consume-on-success, and (d) resume-from-existing-asset-lock would pin the orchestration shape. PR description marks end-to-end testnet validation as still pending.

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 210)

Verified at 06c1930 (lines 214-216 unchanged): the doc on decode_funding_addresses claims it is 'Shared with the legacy raw-private-key [crate::platform_addresses::fund_from_asset_lock] FFI so both entry points agree on the wire shape.' Confirmed false — platform_addresses/fund_from_asset_lock.rs:35-44 still has its own inline for entry in from_raw_parts(...) decode loop and never calls decode_funding_addresses. The two FFI decode paths therefore do not share logic, so any future tightening of one (duplicate rejection, null handling, P2SH boundary check, error wording) will silently diverge across the boundary. Either route the legacy FFI through decode_funding_addresses to make the comment true, or correct the comment.

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 218)

Verified at 06c1930 (lines 218-226): the // Safety doc requires non-null addresses, but the body unconditionally calls std::slice::from_raw_parts(addresses, addresses_count). Per the slice contract this is UB on a null data pointer even when count == 0. Today's two FFI entry points gate with check_ptr!(addresses) before the call, so current call sites are sound. But the helper is pub(super) and sits on a C ABI trust boundary consuming caller-supplied raw pointers; a future intra-module caller that omits check_ptr! — or fast-paths addresses_count == 0 on the hunch that 'empty can't matter' — would silently introduce UB the optimizer is free to compile into a memory-safety bug. Sibling helpers in this crate (parse_outputs, parse_explicit_inputs) defensively null-check internally; aligning here costs nothing and removes a sharp edge from a security boundary.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/StorageRecordDetailViews.swift (1)

2044-2127: 💤 Low value

Consider extracting bech32m helpers to a shared utility.

These ~80 lines of bech32m encoding logic are correct but could be reused elsewhere (e.g., if other views need to display platform addresses). For now this is acceptable as display-only code in an example app, but if platform address rendering spreads to more surfaces, extracting to a shared Bech32m utility would reduce duplication.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/StorageRecordDetailViews.swift`
around lines 2044 - 2127, This code block duplicates bech32m logic and should be
extracted to a reusable utility: create a new Bech32m (or Bech32mUtils)
module/class and move the functions convertBits, bech32mEncode,
bech32mCreateChecksum, bech32mHRPExpand and bech32mPolymod into it as
public/static helpers; update StorageRecordDetailViews to import/use that
utility (call Bech32m.bech32mEncode(...) etc.), keep signatures and behavior
identical, and add a small unit test or usage example to ensure parity after
refactor.

packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/ManagedPlatformAddressWallet.swift (line 594)

fundFromCoreAssetLockPreflight checks only non-empty input, the single-nil remainder invariant, and hash.count == 20. Both funding entry points then pass FundingRecipient.addressType through unchanged, but PlatformAddress::try_from in Rust accepts only address_type == 0, and validate_recipient_addresses rejects non-P2PKH recipients as well. That means unsupported recipient types pass the synchronous Swift preflight and fail only after the async FFI setup and Rust call begin, which defeats the point of the preflight guard.

for r in recipients {
    guard r.addressType == 0 else {
        throw PlatformWalletError.invalidParameter(
            "FundingRecipient.addressType currently supports only 0 (P2PKH); got \(r.addressType)"
        )
    }
    guard r.hash.count == 20 else {
        throw PlatformWalletError.invalidParameter(
            "FundingRecipient.hash must be exactly 20 bytes (got \(r.hash.count))"
        )
    }
}

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 210)

decode_funding_addresses inserts each entry into a BTreeMap and ignores the return value from insert, so duplicate platform addresses are silently overwritten at the ABI boundary. That changes the recipient set after Swift has already chosen the fee strategy and the single None remainder target. The helper's own comment claims this logic is shared with the legacy raw-key FFI path, but platform_addresses/fund_from_asset_lock.rs still has a separate inline decode loop, so the two entry points can keep drifting on duplicate rejection and other validation rules.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/AddressFundingProgressView.swift (line 61)

The @Query is still scoped only by walletId and fundingTypeRaw == 4, and every step computation reads activeLocks.first. AddressFundingController is keyed by (walletId, platformAccountIndex, recipientHash), but PersistentAssetLock still does not carry that discriminator while the funding is in flight. If two address top-ups run concurrently on the same wallet, both progress views observe the same lock set and whichever row updated most recently drives both steppers.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/StorageRecordDetailViews.swift (line 2012)

networkHRP() always returns "tdash". The storage view therefore renders mainnet recipient platform addresses with a testnet bech32m prefix, which is not just cosmetic: copying that string back into Rust-side parsing fails on network mismatch. The surrounding comment says the code should derive the HRP from the owning wallet, but this implementation never does.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/FundPlatformAddressView.swift (line 621)

backfillRecipientOnConsumedLock still selects the newest row matching (walletId, fundingTypeRaw == 4, statusRaw == 4, recipientPlatformAddressHash == nil) and stamps that row with the current controller's recipient hash. If two fundings complete close together on the same wallet, callback ordering can stamp the wrong consumed lock. The method also hardcodes recipientPlatformAddressType = 0, so even if another address type is submitted later the stored audit trail is forced to P2PKH.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/PendingPlatformFundingsList.swift (line 45)

The exclusion set is built with inFlight.compactMap { _ in nil }, so it is always empty. That means a lock already owned by an in-flight controller can also appear in the resumable-orphan list while its persisted row is still in statuses 1...3. The user can then trigger a second resume submission against the same outpoint and hit a later duplicate rejection instead of being prevented at the UI layer.

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 201)

After a successful top-up, fund_addresses_with_funding writes the new balances into the managed account and returns the PlatformAddressChangeSet, but it never calls self.persister.store(cs.clone().into()). Other mutating address flows such as transfer persist immediately for exactly this reason. If the process dies before a later sync runs, the platform accepted the top-up but persisted local state still reflects the old balances, which can break restart-time balance display and input selection.

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 88)

There are still no tests that exercise fund_addresses_with_funding itself. The method owns the recipient preflight, funding resolution, IS-timeout fallback, IS-rejection fallback, CL-height retry wiring, balance writeback, and consume-on-success cleanup. The repository only has a dedicated test for the lower-level submit_with_cl_height_retry helper, so the most failure-prone branches in this new orchestrator remain unpinned.

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 218)

decode_funding_addresses documents that addresses must be non-null, but it immediately calls std::slice::from_raw_parts(addresses, addresses_count) without enforcing that precondition itself. The current extern entry points do call check_ptr!(addresses) first, so this is not an immediate exploit in the shipped API, but the helper is reusable within the module and a future caller can reintroduce UB by forgetting that outer guard. This null check belongs in the unsafe helper itself, not in every caller's memory.

pub(super) unsafe fn decode_funding_addresses(
    addresses: *const FundingAddressEntryFFI,
    addresses_count: usize,
) -> Result<BTreeMap<PlatformAddress, Option<dpp::fee::Credits>>, PlatformWalletFFIResult> {
    if addresses.is_null() {
        return Err(PlatformWalletFFIResult::err(
            PlatformWalletFFIResultCode::ErrorInvalidParameter,
            "addresses pointer is null",
        ));
    }

    let mut address_map = BTreeMap::new();
    for entry in std::slice::from_raw_parts(addresses, addresses_count) {
        let addr = PlatformAddress::try_from(entry.address).map_err(|e| {
            PlatformWalletFFIResult::err(
                PlatformWalletFFIResultCode::ErrorInvalidParameter,
                format!("invalid platform address: {e}"),
            )
        })?;
        let balance = if entry.has_balance {
            Some(entry.balance)
        } else {
            None
        };
        address_map.insert(addr, balance);
    }
    Ok(address_map)
}

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/AddressFundingProgressView.swift (line 176)

step3WasSkipped now returns lock.statusRaw != 2, and stepState uses that once the flow advances past step 3. On the timeout-fallback path, step 3 is actually active for up to instantLockTimeout while the row remains statusRaw == 1; after the fallback succeeds and the row becomes statusRaw == 3, the UI retroactively fades that completed wait as a skipped step. The new implementation therefore loses history for the common IS-timeout path and misrepresents what the user just waited through.

packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/ManagedPlatformAddressWallet.swift (line 594)

Verified at 0a0ba19: fundFromCoreAssetLockPreflight only checks non-empty input, the single-nil remainder invariant, and hash.count == 20 — it does not validate addressType. Both funding entry points then marshal FundingRecipient.addressType unchanged into PlatformAddressFFI, but TryFrom<PlatformAddressFFI> for PlatformAddress (packages/rs-platform-wallet-ffi/src/platform_address_types.rs:37-43) only accepts address_type == 0, and the Rust wallet path rejects non-P2PKH again in validate_recipient_addresses (packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs:335-341). Unsupported recipient types pass the synchronous Swift guard and fail only after Task setup + the Rust call begin, which defeats the stated purpose of the preflight. Add a guard r.addressType == 0 check next to the hash.count guard.

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 223)

Verified at 0a0ba19 (lines 227-241): decode_funding_addresses inserts each FFI entry into a BTreeMap<PlatformAddress, Option<Credits>> and ignores insert's return value. If the caller passes the same PlatformAddress twice, the later row silently overwrites the earlier one at the ABI boundary. Swift computes its remainder output index and fee strategy from the ordered ffiAddresses array before the FFI call, so this is input-shape drift across the boundary — Rust can execute a different recipient set than Swift sized. The header comment also still claims this decoder is shared with the legacy raw-key FFI path, but fund_from_asset_lock.rs:35-44 keeps a separate inline decode loop, so the two entry points can continue diverging on validation. Surface a structured ErrorInvalidParameter on duplicate insert and route both entry points through this helper to close the drift.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/AddressFundingProgressView.swift (line 58)

Verified at 0a0ba19: the @Query is scoped only by walletId and fundingTypeRaw == 4, and the step logic derives state from activeLocks.first (used by currentStep, step3WasSkipped, step4WasSkipped). AddressFundingController is keyed by (walletId, platformAccountIndex, recipientHash), but PersistentAssetLock has no equivalent per-recipient/outpoint discriminator populated while the funding is in flight (the recipient hash is documented as being populated only after success). With two concurrent address top-ups on the same wallet, both progress views observe the same lock set, and whichever row most recently sorted to first drives both steppers. Plumb the asset-lock outpoint into the controller after broadcast and filter the query by it.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/FundPlatformAddressView.swift (line 629)

Verified at 0a0ba19: backfillRecipientOnConsumedLock fetches the newest row matching (walletId, fundingTypeRaw == 4, statusRaw == 4, recipientPlatformAddressHash == nil) (fetchLimit 1, sorted by updatedAt desc) and stamps it with the current controller's recipientHash and a hardcoded recipientPlatformAddressType = 0. When two fundings complete close together, SwiftData persistence ordering is independent of controller completion ordering, so one controller can stamp the other funding's consumed row. The hardcoded P2PKH type byte also locks the storage-explorer audit trail to P2PKH even if the FFI eventually accepts another address type. The comment acknowledges this; the fix is to thread the outpoint through AddressFundingController so the back-fill can address its own row directly, and to capture the original FFI addressType rather than hardcoding 0.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/PendingPlatformFundingsList.swift (line 45)

Verified at 0a0ba19: orphans = resumableLocks(excludingControllerOutpoints: Set(inFlight.compactMap { _ in nil })) — the exclusion set is always empty by construction. The inline comment acknowledges that controllers don't currently track the outpoint they're driving. Resumable rows are identified by PersistentAssetLock.outPointHex, so the same persisted lock can simultaneously appear as an in-flight controller row and as a resumable orphan. Tapping Resume can launch a second FFI submission against the same Rust-tracked outpoint with a different recipient hash; Platform rejects the duplicate later, but the UI should not have lost the outpoint identity in the first place. Persist the outpoint on the controller after broadcast and de-dupe here.

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 201)

Verified at 0a0ba19 (lines 205-223): after a successful submit, fund_addresses_with_funding calls write_address_balances_changeset to update ManagedPlatformAccount in memory and returns the resulting PlatformAddressChangeSet, but it never pushes the changeset through self.persister.store(...) before consuming the asset lock. Other mutating address flows such as transfer (packages/rs-platform-wallet/src/wallet/platform_addresses/transfer.rs:145-159) persist immediately for exactly this reason. The Swift caller only receives an ephemeral decoded [UpdatedBalance]; on restart it rebuilds from persistence, not from that transient array. If the process dies before the next sync, Platform has accepted the top-up but persisted wallet state still reflects the old balances, which can poison initialize_from_persisted and downstream input selection.

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 88)

Verified at 0a0ba19: fund_addresses_with_funding owns the end-to-end orchestration — recipient preflight, funding resolution, InstantSend-timeout fallback, IS-rejection fallback (the second submit_with_cl_height_retry(settings, ...) call intentionally restarts from the original PutSettings after switching proof type), CL-height retry wiring, balance writeback, and consume_asset_lock cleanup. The repository only pins the lower-level submit_with_cl_height_retry helper in wallet/asset_lock/orchestration.rs; there is no direct test exercising this method's own control flow. A future refactor that changes that PutSettings ownership pattern or the IS→CL switchover would be easy to write and hard to catch. Add targeted tests covering the IS-timeout, IS-rejection, and success-with-cleanup branches.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/AddressFundingProgressView.swift (line 176)

Verified at 0a0ba19: step3WasSkipped returns lock.statusRaw != 2, and stepState uses it once the flow advances past step 3. On the IS-timeout fallback path, step 3 is actually active for up to instantLockTimeout (300 s) while the row remains statusRaw == 1; after the CL fallback succeeds and the row becomes statusRaw == 3, the UI retroactively fades the completed IS wait as a skipped step. The current doc comment explains the simplification, but the history shown to the user is still inaccurate on the common IS-timeout path. Either distinguish 'IS timed out → fell back to CL' from 'CL came in directly without IS attempt' using broadcastSubStep's elapsed value at completion, or relabel step 3 so the skipped-state isn't misleading.

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 220)

Verified at 0a0ba19 (lines 223-228): decode_funding_addresses is unsafe pub(super) and immediately calls std::slice::from_raw_parts(addresses, addresses_count) without checking addresses.is_null(). Under Rust's slice contract, from_raw_parts(NULL, 0) is UB. The two current exported entry points call check_ptr!(addresses) first, so the shipped paths are sound today, but this helper sits exactly at the trust boundary for the raw address array and is reusable within the module — one forgotten outer guard reintroduces UB with no type-system resistance. Sibling parsers in platform_address_types.rs defend themselves internally, which is the safer shape. Move the null check inside the helper.

packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/ManagedPlatformAddressWallet.swift (line 594)

Verified at 43efe2e (lines 594-613, unchanged in this delta): fundFromCoreAssetLockPreflight validates non-emptiness, the single-nil remainder invariant, and hash.count == 20, but never inspects addressType. Both entry points then marshal FundingRecipient.addressType unchanged into PlatformAddressFFI. On the Rust side, TryFrom<PlatformAddressFFI> for PlatformAddress accepts only address_type == 0, and validate_recipient_addresses enforces P2PKH-only. Unsupported types pass the synchronous preflight, spin up the Task, marshal the handle, and only then surface a generic invalid-parameter error from Rust — defeating the documented purpose of the preflight (deliver a synchronous error before paying for the Task detach). This is also now load-bearing for the new recipientType plumbing: a non-zero addressType that bypasses validation here taints the recipientPlatformAddressType audit field stamped by the back-fill. Mirror the Rust invariant explicitly next to the hash.count guard.

        for r in recipients {
            guard r.addressType == 0 else {
                throw PlatformWalletError.invalidParameter(
                    "FundingRecipient.addressType currently supports only 0 (P2PKH); got \(r.addressType)"
                )
            }
            guard r.hash.count == 20 else {
                throw PlatformWalletError.invalidParameter(
                    "FundingRecipient.hash must be exactly 20 bytes (got \(r.hash.count))"
                )
            }
        }

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 237)

Verified at 43efe2e: line 250 address_map.insert(addr, balance); discards the Option returned by BTreeMap::insert. The new empty-count short-circuit doesn't change this path. Two consequences at the C ABI trust boundary: (a) the funded output set the Rust orchestrator executes diverges from the ordered [FundingRecipient] array Swift sized the fee strategy and the single-None remainder against — after dedup Rust may see a different recipient set and a different remainder target than the fee strategy was computed against; (b) if the duplicate row flips has_balance, the lone None remainder slot can shift after dedup, redirecting fees and remainder credits silently. The doc comment claims this helper is shared with the legacy raw-key FFI, but fund_from_asset_lock.rs:35-44 still has its own inline decode loop — the two FFI decode paths therefore do not share logic and will silently diverge on any future tightening. Reject duplicates explicitly with ErrorInvalidParameter so the input shape the caller passes is the input shape the orchestrator executes.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/AddressFundingProgressView.swift (line 58)

Verified at 43efe2e (lines 67-72, unchanged): _activeLocks is Query-scoped only by walletId == walletId && fundingTypeRaw == 4, sorted by updatedAt desc; currentStep, step3WasSkipped, step4WasSkipped, broadcastSubStep all key off activeLocks.first. AddressFundingController is keyed (walletId, platformAccountIndex, recipientHash) precisely to allow concurrent fundings, but PersistentAssetLock carries no recipient-hash discriminator during the in-flight phase (recipientPlatformAddressHash is stamped only post-Consumed). Two concurrent address top-ups on one wallet observe the same lock set, and whichever row most recently sorted to first drives both steppers — Funding A's UI can advance to Step 3 because Funding B's lock just transitioned to Broadcast. The new PendingPlatformFundingsList explicitly invites concurrent fundings to coexist, so this matters more, not less. Fix shape: propagate the asset-lock outpoint into the controller after broadcast and scope the query by it (same plumbing as finding #4).

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/PendingPlatformFundingsList.swift (line 45)

Verified at 43efe2e (lines 45-58, unchanged): orphans = resumableLocks(excludingControllerOutpoints: Set(inFlight.compactMap { _ in nil })) — every entry returns nil, so the exclusion set is always empty. The inline comment acknowledges this. The SwiftData status filter (statusRaw ∈ [1,3]) excludes Consumed locks, but an in-flight controller whose asset lock has just broadcast sits in status 2/3 long enough to render in the orphan list while its driving controller is concurrently in the in-flight list. Tapping Resume opens FundPlatformAddressView in resume mode against the same outpoint; the user can pick a different recipient than the original flow, and the coordinator's single-flight gate (keyed on (walletId, platformAccountIndex, recipientHash)) doesn't catch the duplicate. Bounded (Platform deterministically rejects the duplicate ST) but the user pays a full FFI round-trip on a guaranteed-to-fail submission. Same fix path as finding #3: have the controller expose its asset-lock outpoint once broadcast and feed it into the exclusion set.

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 285)

Verified at 43efe2e (lines 285-328): after a successful submit, write_address_balances_changeset mutates ManagedPlatformAccount in memory and returns PlatformAddressChangeSet, but the orchestrator goes straight to consume_asset_lock and Ok(cs) without invoking self.persister.store(cs.clone().into()). Sister flows persist explicitly: transfer.rs:156 and sync.rs:80 both call self.persister.store(cs.into()). The new IS→CL queue_asset_lock_changeset call DOES persist the asset-lock side of the world, but the address-balance changeset returned to the FFI still never lands in the persister. A crash between consume_asset_lock and the next BLAST sync leaves a window where Platform has accepted the top-up but the local SwiftData store doesn't know the new credit balance — affecting auto-input selection and any UI reading balances from the persisted store. The new consume_asset_lock warn-vs-error classification implicitly assumes the changeset has already been durably recorded — it hasn't.

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 127)

Verified at 43efe2e: submit_with_cl_height_retry has an explicit regression-pinning test, but the new orchestrator composing preflight, funding resolution, IS→CL timeout fallback, IS-rejection fallback, retry submission, balance writeback, and asset-lock consume has no direct test. This delta added behaviorally distinct branches that are also unpinned: (a) the IS-rejection path now advances tracked status InstantSendLocked → ChainLocked via advance_asset_lock_status + queue_asset_lock_changeset BEFORE the second submit_with_cl_height_retry, load-bearing for the truthful-status-on-double-failure invariant; (b) the empty-address_infos post-condition returning PlatformWalletError::AddressSync(...) instead of consuming the asset lock; (c) the split warn/error logging on consume_asset_lock failure; (d) the per-recipient skip-and-continue path in write_address_balances_changeset. A targeted #[tokio::test(start_paused = true)] set would pin the orchestration shape. PR description still marks end-to-end testnet validation as pending.

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 267)

New in this delta. The post-condition at lines 275-283 hardens the all-empty case: address_infos.is_empty() returns AddressSync and the asset lock stays Resumable. But the partial case is not symmetric. expected_recipient_count = addresses.len() is captured but never used as an invariant. Downstream in write_address_balances_changeset (lines 360-412), each requested recipient missing from address_infos emits tracing::error! and continues — correctly avoiding the prior 'credited 0' shape — but the orchestrator then proceeds to consume_asset_lock(out_point) unconditionally on the success path. A proof that returns AddressInfo for N-1 of N requested recipients therefore consumes the asset lock with one recipient invisibly dropped from the persisted changeset. User-visible outcome: ST succeeded, asset lock is gone, one recipient never gets a balance row, and the only signal is a tracing::error! (no metric / structured error). Either extend the post-condition to address_infos.len() == addresses.len() and refuse to consume on shortfall, or surface a structured PlatformWalletError::ProofIncomplete variant the caller can react to.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/FundPlatformAddressView.swift (line 691)

New in this delta (3fd355b). Verified at lines 708-731 (default branch of the switch newRows.count): when two address-funding flows resolve Consumed in the same .onChange window, both controllers see newRows.count > 1 and both refuse to stamp. The accompanying doc comment claims controllers 'will retry on their next phase tick … in practice one will land first and the other re-runs against the now-smaller delta.' But .completed is the terminal phase of AddressFundingController.phase; the controller does not keep ticking after it lands there, and .onChange(of: controller?.phase) fires once per transition into .completed. If both controllers' .completed transitions land on the same MainActor turn (or close enough that both .onChange closures run before either back-fill saves), both back-fills see the same multi-element delta, both refuse, and neither row is stamped — permanently. The fallback is UX-only (storage explorer shows '—' on both rows), not a correctness defect. Fix: in the multi-match branch, stamp the row matching the current controller's outpoint if the controller has one — the natural place to surface it is the same plumbing findings #3/#4 want.

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 220)

Verified at 43efe2e: the new short-circuit at lines 234-236 returns early when addresses_count == 0 and the SAFETY doc was tightened to say a 0-count dangling sentinel is sound. That closes the dominant UB hole prior #9 called out (from_raw_parts(NULL, 0)). When addresses_count > 0 the helper still calls std::slice::from_raw_parts(addresses, addresses_count) without addresses.is_null(). Today's two FFI entry points gate with check_ptr!(addresses) before the call, so current call sites are sound. The helper is pub(super) and sits on a C ABI trust boundary; a future intra-module caller that forgets check_ptr! for the non-zero case would reintroduce UB the optimizer is free to compile into a memory-safety bug. Sibling FFI decoders in platform_address_types.rs defensively null-check internally; aligning here costs nothing and removes a sharp edge from a security boundary.

packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/ManagedPlatformAddressWallet.swift (line 594)

Verified at e27dcba (lines 594-613, unchanged). fundFromCoreAssetLockPreflight validates non-emptiness, the single-nil remainder invariant, and hash.count == 20, but never inspects addressType. Both fundFromCoreAssetLock and resumeFundFromAssetLock then marshal FundingRecipient.addressType unchanged into PlatformAddressFFI. On the Rust side, TryFrom<PlatformAddressFFI> for PlatformAddress (platform_address_types.rs) accepts only address_type == 0, and validate_recipient_addresses re-enforces P2PKH-only. Unsupported types pass the synchronous preflight, spin up the Task, marshal the handle, and only then surface a generic invalid-parameter error from Rust — defeating the documented purpose of the preflight (synchronous fail-fast before paying for Task detach + handle marshaling). Also load-bearing for the new recipientPlatformAddressType audit field: a non-zero addressType that bypasses this guard taints what the back-fill stamps. Mirror the Rust invariant explicitly next to the hash.count guard.

        for r in recipients {
            guard r.addressType == 0 else {
                throw PlatformWalletError.invalidParameter(
                    "FundingRecipient.addressType currently supports only 0 (P2PKH); got \(r.addressType)"
                )
            }
            guard r.hash.count == 20 else {
                throw PlatformWalletError.invalidParameter(
                    "FundingRecipient.hash must be exactly 20 bytes (got \(r.hash.count))"
                )
            }
        }

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 237)

Verified at e27dcba (line 250 unchanged). address_map.insert(addr, balance); discards the Option returned by BTreeMap::insert, so duplicate PlatformAddress entries silently overwrite at the C ABI trust boundary. Two consequences: (a) the funded output set the Rust orchestrator executes diverges from the ordered [FundingRecipient] array Swift sized the fee strategy and the single-None remainder against — after dedup Rust may see a smaller recipient set and a different remainder target than the fee strategy was computed against; (b) if the duplicate row flips has_balance, the lone None remainder slot can shift, redirecting fee remainder credits to a different address than the caller computed against, with no typed error crossing the boundary. The doc comment (lines 216-218) claims this helper is shared with the legacy raw-key FFI, but fund_from_asset_lock.rs:35-44 still has its own inline decode loop — the two FFI decoders have already drifted on duplicate handling. Reject duplicates with ErrorInvalidParameter so the input shape the caller passes is the input shape the orchestrator executes, and route both entry points through this helper.

    let mut address_map = BTreeMap::new();
    for entry in std::slice::from_raw_parts(addresses, addresses_count) {
        let addr = PlatformAddress::try_from(entry.address).map_err(|e| {
            PlatformWalletFFIResult::err(
                PlatformWalletFFIResultCode::ErrorInvalidParameter,
                format!("invalid platform address: {e}"),
            )
        })?;
        let balance = if entry.has_balance {
            Some(entry.balance)
        } else {
            None
        };
        if address_map.insert(addr, balance).is_some() {
            return Err(PlatformWalletFFIResult::err(
                PlatformWalletFFIResultCode::ErrorInvalidParameter,
                "duplicate platform address in funding recipient list".to_string(),
            ));
        }
    }
    Ok(address_map)

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 285)

Verified at e27dcba (lines 285-328 unchanged). After a successful submit, write_address_balances_changeset mutates ManagedPlatformAccount in memory and returns PlatformAddressChangeSet, but the orchestrator goes straight to consume_asset_lock and Ok(cs) without invoking self.persister.store(cs.clone().into()). Sister flows persist explicitly: transfer.rs:156 and sync.rs:80 both call self.persister.store(cs.into()). The IS→CL queue_asset_lock_changeset DOES persist the asset-lock side, but the address-balance changeset returned to the FFI never lands in the persister. A crash between consume_asset_lock and the next BLAST sync leaves a window where Platform has accepted the top-up but the local SwiftData store doesn't know the new credit balance — affecting auto-input selection and any UI reading balances from the persisted store. The consume_asset_lock warn-vs-error classification implicitly assumes the changeset has already been durably recorded; it hasn't.

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 267)

Verified at e27dcba (lines 267-326 unchanged). The post-condition (lines 275-283) hardens the all-empty case: address_infos.is_empty() returns AddressSync and the asset lock stays Resumable. The partial case is not symmetric. expected_recipient_count = addresses.len() is captured (line 275) but never compared as an invariant. Downstream in write_address_balances_changeset, each requested recipient missing from address_infos emits tracing::error! and continues, but the orchestrator then proceeds to consume_asset_lock(out_point) unconditionally on the success path. A proof returning AddressInfo for N-1 of N requested recipients therefore consumes the asset lock with one recipient invisibly dropped from the persisted changeset. Threat model: a buggy or compromised DAPI intermediary can stitch a proof that attests for fewer recipients than requested — the client refuses to recurse but still consumes its own asset lock, so the user pays on-chain locked Dash while one recipient's audit row is marked Consumed with no balance changeset. The only signal is a tracing::error! (no metric, no structured error). Either extend the post-condition to address_infos.len() == expected_recipient_count and refuse to consume on shortfall, or surface a structured PlatformWalletError::ProofIncomplete variant the caller can react to.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/AddressFundingProgressView.swift (line 58)

Verified at e27dcba (unchanged). _activeLocks is @Query-scoped only by walletId == walletId && fundingTypeRaw == 4, sorted by updatedAt desc; currentStep, step3WasSkipped, step4WasSkipped, and broadcastSubStep all key off activeLocks.first. AddressFundingController is keyed by (walletId, platformAccountIndex, recipientHash) precisely to allow concurrent fundings, but PersistentAssetLock carries no recipient-hash discriminator during the in-flight phase (recipientPlatformAddressHash is stamped only post-Consumed). With two concurrent address top-ups on one wallet, both progress views observe the same lock set and whichever row most recently sorted to first drives both steppers — Funding A's UI can advance to Step 3 because Funding B's lock just transitioned to Broadcast. The PendingPlatformFundingsList explicitly invites concurrent fundings to coexist, so this matters more, not less. Fix shape: plumb the asset-lock outpoint into the controller after broadcast and scope the query by it.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/PendingPlatformFundingsList.swift (line 45)

Verified at e27dcba (unchanged). orphans = resumableLocks(excludingControllerOutpoints: Set(inFlight.compactMap { _ in nil })) — every entry returns nil, so the exclusion set is always empty by construction (the inline comment acknowledges this). The SwiftData status filter (statusRaw ∈ [1,3]) excludes Consumed locks, but an in-flight controller whose asset lock has just broadcast sits in status 2/3 long enough to render in the orphan list while its driving controller is concurrently in the in-flight list. Tapping Resume opens FundPlatformAddressView in resume mode against the same outpoint; the user can pick a different recipient, and the coordinator's single-flight gate (keyed on (walletId, platformAccountIndex, recipientHash)) doesn't catch the duplicate because the second submission keys differently. Bounded (Platform deterministically rejects the duplicate ST) but the user pays a full FFI round-trip on a guaranteed-to-fail submission. Same fix path as the progress-view finding: have the controller expose its asset-lock outpoint once broadcast and feed it into the exclusion set.

packages/rs-platform-wallet/src/wallet/platform_addresses/fund_with_funding.rs (line 127)

Verified at e27dcba. submit_with_cl_height_retry has an explicit regression-pinning test, but the orchestrator composing preflight, funding resolution, IS→CL timeout fallback, IS-rejection fallback, retry submission, balance writeback, and asset-lock consume has no direct test. Behaviorally distinct branches added in PR #3671 that remain unpinned: (a) the IS-rejection path advancing tracked status InstantSendLocked → ChainLocked via advance_asset_lock_status + queue_asset_lock_changeset BEFORE the second submit_with_cl_height_retry — load-bearing for the truthful-status-on-double-failure invariant; (b) the empty-address_infos post-condition returning PlatformWalletError::AddressSync(...) instead of consuming the asset lock; (c) the split warn/error logging on consume_asset_lock failure; (d) the per-recipient skip-and-continue path in write_address_balances_changeset. A targeted #[tokio::test(start_paused = true)] set would pin the orchestration shape. PR description still marks end-to-end testnet validation as pending.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/FundPlatformAddressView.swift (line 708)

Verified at e27dcba (unchanged). In the default branch of the switch newRows.count block, when two address-funding flows resolve Consumed in the same .onChange window, both controllers see newRows.count > 1 and both refuse to stamp. The doc comment claims controllers 'will retry on their next phase tick … in practice one will land first and the other re-runs against the now-smaller delta.' But .completed is the terminal phase of AddressFundingController.phase; the controller does not keep ticking after it lands there, and .onChange(of: controller?.phase) fires once per transition into .completed. If both controllers' .completed transitions land on the same MainActor turn (or close enough that both .onChange closures run before either back-fill saves), both back-fills see the same multi-element delta, both refuse, and neither row is stamped — permanently. The fallback is UX-only (storage explorer shows '—' on both rows), not a correctness defect. Fix: in the multi-match branch, stamp the row matching the current controller's outpoint if the controller has one — same plumbing the progress-view and orphan-list findings want.

packages/rs-platform-wallet-ffi/src/platform_addresses/fund_with_funding.rs (line 226)

Verified at e27dcba (unchanged). The short-circuit at lines 234-236 returns early when addresses_count == 0 and the SAFETY doc was tightened to scope the non-null obligation to that case, closing the dominant UB hole (from_raw_parts(NULL, 0)). When addresses_count > 0 (line 238) the helper still calls std::slice::from_raw_parts(addresses, addresses_count) without verifying !addresses.is_null(). Today's two FFI entry points gate with check_ptr!(addresses) before the call, so current call sites are sound. The helper is pub(super) and sits on a C ABI trust boundary; a future intra-module caller that omits check_ptr! for the non-zero case would reintroduce UB the optimizer is free to compile into a memory-safety bug on attacker-controlled FFI input. Sibling decoders in platform_address_types.rs defensively null-check internally — aligning here removes a sharp edge from a security boundary at zero runtime cost.

packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/ManagedPlatformAddressWallet.swift (line 594)

Verified at 08c4443 (file/lines confirmed; preflight body at 594-613). topUpFromCorePreflight validates non-emptiness, the single-nil remainder invariant, and hash.count == 20, but never inspects addressType. Both entry points marshal TopUpRecipient.addressType unchanged into PlatformAddressFFI. Rust-side TryFrom<PlatformAddressFFI> for PlatformAddress (packages/rs-platform-wallet-ffi/src/platform_address_types.rs) accepts only address_type == 0, and validate_recipient_addresses in top_up.rs re-enforces P2PKH-only. Unsupported types pass the synchronous preflight, the Task is detached, the FFI is entered, and only then a generic invalid-parameter error surfaces — defeating the documented purpose of the preflight (synchronous fail-fast before paying for Task detach + handle marshaling, per the doc comment at lines 590-593). Also load-bearing for the new recipientPlatformAddressType audit field: a non-zero addressType bypassing this guard taints what the back-fill stamps onto the consumed lock row. Mirror the Rust invariant next to the existing hash.count == 20 guard.

        for r in recipients {
            guard r.addressType == 0 else {
                throw PlatformWalletError.invalidParameter(
                    "TopUpRecipient.addressType currently supports only 0 (P2PKH); got \(r.addressType)"
                )
            }
            guard r.hash.count == 20 else {
                throw PlatformWalletError.invalidParameter(
                    "TopUpRecipient.hash must be exactly 20 bytes (got \(r.hash.count))"
                )
            }
        }

packages/rs-platform-wallet-ffi/src/platform_addresses/top_up.rs (line 233)

Verified at 08c4443 (line 246 confirmed: address_map.insert(addr, balance); discards the Option). At the C ABI trust boundary, duplicate PlatformAddress entries silently overwrite. Two consequences: (a) the funded output set the Rust orchestrator executes diverges from the ordered [TopUpRecipient] array Swift sized the fee strategy and the single-nil remainder against — after dedup Rust may see a smaller recipient set with a different remainder target than the fee strategy was computed against; (b) if the duplicate row flips has_balance, the lone None remainder slot can shift, redirecting fee remainder credits to a different address than the caller computed against, with no typed error crossing the boundary. The legacy fund_from_asset_lock.rs FFI was removed in commit c7828f8, so decode_funding_addresses is now the SOLE FFI decode path for address-fund recipients — the canonical place to enforce the input-shape invariant. Reject duplicates with ErrorInvalidParameter so the input shape the caller passes is the input shape the orchestrator executes.

    if addresses_count == 0 {
        return Ok(BTreeMap::new());
    }
    let mut address_map = BTreeMap::new();
    for entry in std::slice::from_raw_parts(addresses, addresses_count) {
        let addr = PlatformAddress::try_from(entry.address).map_err(|e| {
            PlatformWalletFFIResult::err(
                PlatformWalletFFIResultCode::ErrorInvalidParameter,
                format!("invalid platform address: {e}"),
            )
        })?;
        let balance = if entry.has_balance {
            Some(entry.balance)
        } else {
            None
        };
        if address_map.insert(addr, balance).is_some() {
            return Err(PlatformWalletFFIResult::err(
                PlatformWalletFFIResultCode::ErrorInvalidParameter,
                "duplicate platform address in top-up recipient list".to_string(),
            ));
        }
    }
    Ok(address_map)

packages/rs-platform-wallet/src/wallet/platform_addresses/top_up.rs (line 283)

Verified at 08c4443 (lines 283-326 confirmed; orchestrator goes write_address_balances_changeset → consume_asset_lock → Ok(cs) with no persister.store call). After a successful submit, write_address_balances_changeset mutates ManagedPlatformAccount in memory and returns PlatformAddressChangeSet, but the orchestrator never invokes self.persister.store(cs.clone().into()). Sister mutating flows persist explicitly: transfer.rs and sync.rs both call self.persister.store(cs.into()). The IS→CL queue_asset_lock_changeset (line 242) DOES persist the asset-lock side, but the address-balance changeset returned to the FFI never lands in the persister. A crash between consume_asset_lock and the next BLAST sync leaves a window where Platform has accepted the top-up but the local SwiftData store doesn't know the new credit balance — affecting auto-input selection and any UI reading balances from the persisted store. The new consume_asset_lock warn-vs-error classification (lines 305-322) implicitly assumes the changeset has already been durably recorded; it hasn't. The doc comment at line 260 promises 'Step 4: bookkeeping + cleanup' but the bookkeeping half stops at in-memory state.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/AddressTopUpProgressView.swift (line 58)

Verified at 08c4443 (file renamed from AddressFundingProgressView.swift; @query scope unchanged). _activeLocks is @Query-scoped only by walletId == walletId && fundingTypeRaw == 4, sorted by updatedAt desc; currentStep, step3WasSkipped, step4WasSkipped, and broadcastSubStep all key off activeLocks.first. AddressTopUpController is keyed by (walletId, platformAccountIndex, recipientHash) precisely to allow concurrent top-ups, but PersistentAssetLock carries no recipient-hash discriminator during the in-flight phase (recipientPlatformAddressHash is stamped only post-Consumed per the new destination convention doc). With two concurrent address top-ups on one wallet, both progress views observe the same lock set and whichever row most recently sorted to first drives both steppers — Top-Up A's UI can advance to Step 3 because Top-Up B's lock just transitioned to Broadcast. PendingPlatformTopUpsList explicitly invites concurrent flows to coexist, so this matters more, not less. Fix shape: plumb the asset-lock outpoint into the controller after broadcast and scope the query by it.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/PendingPlatformTopUpsList.swift (line 45)

Verified at 08c4443 (file renamed from PendingPlatformFundingsList.swift). orphans = resumableLocks(excludingControllerOutpoints: Set(inFlight.compactMap { _ in nil })) — every compactMap entry returns nil, so the exclusion set is always empty by construction (the inline comment at lines 48-57 acknowledges this and notes the plumbing is here for a future tweak). The SwiftData status filter (statusRaw ∈ [1,3]) excludes Consumed locks, but an in-flight controller whose asset lock has just broadcast sits in status 2/3 long enough to render in the orphan list while its driving controller is concurrently in the in-flight list. Tapping Resume opens TopUpPlatformAddressView in resume mode against the same outpoint; the user can pick a different recipient, and the coordinator's single-flight gate (keyed on (walletId, platformAccountIndex, recipientHash)) doesn't catch the duplicate because the second submission keys differently. Bounded (Platform deterministically rejects the duplicate ST) but the user pays a full FFI round-trip on a guaranteed-to-fail submission. Same fix path as the progress-view finding: have the controller expose its asset-lock outpoint once broadcast and feed it into the exclusion set.

packages/rs-platform-wallet/src/wallet/platform_addresses/top_up.rs (line 265)

Verified at 08c4443 (lines 273-281 confirmed: only address_infos.is_empty() is rejected). The post-condition hardens the all-empty case: returns AddressSync and the asset lock stays Resumable. The partial case is not symmetric. expected_recipient_count = addresses.len() is captured (line 273) but only used in the error message, never compared as an invariant. Downstream in write_address_balances_changeset, each requested recipient missing from address_infos emits tracing::error! and continues, but the orchestrator then proceeds to consume_asset_lock(out_point) (line 304) unconditionally on the success path. A proof returning AddressInfo for N-1 of N requested recipients therefore consumes the asset lock with one recipient invisibly dropped from the persisted changeset. Threat model: a buggy or compromised DAPI intermediary can stitch a proof that attests for fewer recipients than requested — the client refuses to recurse but still consumes its own asset lock, so the user pays on-chain locked Dash while one recipient's audit row is marked Consumed with no balance changeset. The only signal is a tracing::error! (no metric, no structured error). Either extend the post-condition to address_infos.len() == expected_recipient_count and refuse to consume on shortfall, or surface a structured PlatformWalletError::ProofIncomplete variant the caller can react to.

        let expected_recipient_count = addresses.len();
        let matched_recipient_count = address_infos
            .iter()
            .filter(|(addr, _)| addresses.contains_key(addr))
            .count();
        if matched_recipient_count != expected_recipient_count {
            return Err(PlatformWalletError::AddressSync(format!(
                "Address-funding ST succeeded but the proof returned {} of {} expected recipient(s); refusing to consume the asset lock on a partial proof result",
                matched_recipient_count,
                expected_recipient_count
            )));
        }

packages/rs-platform-wallet/src/wallet/platform_addresses/top_up.rs (line 129)

Verified at 08c4443 (method renamed fund_addresses_with_funding → top_up; no orchestration tests added). submit_with_cl_height_retry has an explicit regression-pinning test in wallet/asset_lock/orchestration.rs, but the orchestrator composing preflight, funding resolution, IS→CL timeout fallback, IS-rejection fallback, retry submission, balance writeback, and asset-lock consume has no direct test. Behaviorally distinct branches that remain unpinned: (a) the IS-rejection path advancing tracked status InstantSendLocked → ChainLocked via advance_asset_lock_status + queue_asset_lock_changeset (lines 234-242) BEFORE the second submit_with_cl_height_retry — load-bearing for the truthful-status-on-double-failure invariant Swift's resume UI consumes; (b) the empty-address_infos post-condition returning PlatformWalletError::AddressSync(...) (lines 274-281) instead of consuming the asset lock — this error variant crosses the FFI boundary to Swift; (c) the split warn/error logging on consume_asset_lock failure (lines 304-322); (d) the per-recipient skip-and-continue path in write_address_balances_changeset. A targeted #[tokio::test(start_paused = true)] set would pin the orchestration shape. PR description still marks end-to-end testnet validation as pending.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/TopUpPlatformAddressView.swift (line 708)

Verified at 08c4443 (file renamed from FundPlatformAddressView.swift; default branch of switch newRows.count unchanged). When two address-top-up flows resolve Consumed in the same .onChange(of: controller?.phase) window, both controllers see newRows.count > 1 and both refuse to stamp. The accompanying doc comment claims controllers 'will retry on their next phase tick … in practice one will land first and the other re-runs against the now-smaller delta.' But .completed is the terminal phase of AddressTopUpController.phase; the controller does not keep ticking after it lands there, and .onChange(of: controller?.phase) fires once per transition into .completed. If both controllers' .completed transitions land on the same MainActor turn (or close enough that both .onChange closures run before either back-fill saves), both back-fills see the same multi-element delta, both refuse, and neither row is stamped — permanently. UX-only (storage explorer shows '—' on both rows), not a correctness defect. Fix: in the multi-match branch, stamp the row matching the current controller's outpoint if the controller has one — same plumbing the progress-view and orphan-list findings want.

packages/rs-platform-wallet-ffi/src/platform_addresses/top_up.rs (line 222)

Verified at 08c4443 (lines 222-249). The short-circuit at lines 230-232 returns early when addresses_count == 0 and the SAFETY doc scopes the non-null obligation to that case, closing the dominant UB hole (from_raw_parts(NULL, 0)). When addresses_count > 0 (line 234) the helper still calls std::slice::from_raw_parts(addresses, addresses_count) without verifying !addresses.is_null(). Both current FFI entry points gate with check_ptr!(addresses) before the call, so current call sites are sound. The helper is pub(super) and sits on a C ABI trust boundary; a future intra-module caller that omits check_ptr! for the non-zero case would reintroduce UB the optimizer is free to compile into a memory-safety bug on attacker-controlled FFI input. The deletion of fund_from_asset_lock.rs makes this helper the sole FFI decode path for address-fund recipients, so any future caller forgetting check_ptr! regresses the entire recipient-decode surface. Sibling decoders in platform_address_types.rs defensively null-check internally — aligning here removes a sharp edge from a security boundary at zero runtime cost.

packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/ManagedPlatformAddressWallet.swift (line 594)

Verified at 3ea2f3a (preflight body unchanged at 594-613). topUpFromCorePreflight validates non-emptiness, the single-nil remainder invariant, and hash.count == 20, but never inspects addressType. Both entry points marshal TopUpRecipient.addressType unchanged into PlatformAddressFFI. Rust-side TryFrom<PlatformAddressFFI> for PlatformAddress accepts only address_type == 0, and validate_recipient_addresses re-enforces P2PKH-only. Unsupported types pass the synchronous preflight, the Task is detached, the FFI is entered, and only then a generic invalid-parameter error surfaces — defeating the documented purpose of the preflight (synchronous fail-fast before paying for Task detach + handle marshaling, per the doc comment at 590-593). Also load-bearing for the recipientPlatformAddressType audit field: a non-zero addressType bypassing this guard would taint what the back-fill stamps onto the consumed lock row. Mirror the Rust invariant next to the existing hash.count == 20 guard.

        for r in recipients {
            guard r.addressType == 0 else {
                throw PlatformWalletError.invalidParameter(
                    "TopUpRecipient.addressType currently supports only 0 (P2PKH); got \(r.addressType)"
                )
            }
            guard r.hash.count == 20 else {
                throw PlatformWalletError.invalidParameter(
                    "TopUpRecipient.hash must be exactly 20 bytes (got \(r.hash.count))"
                )
            }
        }

packages/rs-platform-wallet/src/wallet/platform_addresses/top_up.rs (line 283)

Verified at 3ea2f3a (grep for persister.store in this file returns no matches; orchestrator goes write_address_balances_changeset → consume_asset_lock → Ok(cs)). After a successful submit, write_address_balances_changeset mutates ManagedPlatformAccount in memory and returns PlatformAddressChangeSet, but the orchestrator never invokes self.persister.store(cs.clone().into()). Sister mutating flows persist explicitly: transfer.rs and sync.rs both call self.persister.store(cs.into()). The IS→CL queue_asset_lock_changeset does persist the asset-lock side, but the address-balance changeset returned to Swift via PlatformAddressChangeSetFFI never lands in the persister. A crash between consume_asset_lock and the next BLAST sync leaves a window where Platform has accepted the top-up but the local SwiftData store doesn't know the new credit balance — affecting auto-input selection and any UI reading balances from the persisted store. On restart, initialize_from_persisted can repopulate balances from stale rows while the asset lock is already marked consumed — exactly the cross-store skew other wallet mutators explicitly avoid. The consume_asset_lock warn-vs-error classification at 304-322 implicitly assumes the changeset has already been durably recorded; it hasn't.

packages/rs-platform-wallet/src/wallet/platform_addresses/top_up.rs (line 265)

Verified at 3ea2f3a (lines 273-281 confirmed: only address_infos.is_empty() is rejected). The post-condition hardens the all-empty case: returns AddressSync and the asset lock stays Resumable. The partial case is not symmetric. expected_recipient_count = addresses.len() is captured at line 273 but only used in the error message, never compared as an invariant. Downstream in write_address_balances_changeset, each requested recipient missing from address_infos emits tracing::error! and continues, but the orchestrator then proceeds to consume_asset_lock(out_point) at 304 unconditionally on the success path. A proof returning AddressInfo for N-1 of N requested recipients therefore consumes the asset lock with one recipient invisibly dropped from both the persisted changeset and the FFI-returned PlatformAddressChangeSetFFI. Threat model: a buggy or compromised DAPI intermediary can stitch a proof attesting for fewer recipients than requested — the client refuses to recurse but still consumes its own asset lock, so the user pays on-chain locked Dash while one recipient's audit row is marked Consumed with no balance changeset. Only signal is a tracing::error! (no metric, no structured error). Either extend the post-condition to compare matched-recipient count against expected_recipient_count and refuse to consume on shortfall, or surface a structured PlatformWalletError::ProofIncomplete variant the FFI caller can react to.

        let expected_recipient_count = addresses.len();
        let matched_recipient_count = address_infos
            .iter()
            .filter(|(addr, _)| addresses.contains_key(addr))
            .count();
        if matched_recipient_count != expected_recipient_count {
            return Err(PlatformWalletError::AddressSync(format!(
                "Address-funding ST succeeded but the proof returned {} of {} expected recipient(s); refusing to consume the asset lock on a partial proof result",
                matched_recipient_count,
                expected_recipient_count
            )));
        }

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/AddressTopUpProgressView.swift (line 58)

Verified at 3ea2f3a (@query scope at 67-72 unchanged). _activeLocks is @Query-scoped only by walletId == walletId && fundingTypeRaw == 4, sorted by updatedAt desc; currentStep, step3WasSkipped, step4WasSkipped, and broadcastSubStep all key off activeLocks.first. AddressTopUpController is keyed by (walletId, platformAccountIndex, recipientHash) precisely to allow concurrent top-ups, but PersistentAssetLock carries no recipient-hash discriminator during the in-flight phase (recipientPlatformAddressHash is stamped only post-Consumed per the destination convention doc). With two concurrent address top-ups on one wallet, both progress views observe the same lock set and whichever row most recently sorted to first drives both steppers — Top-Up A's UI can advance to Step 3 because Top-Up B's lock just transitioned to Broadcast. PendingPlatformTopUpsList explicitly invites concurrent flows to coexist, so this matters more, not less. Fix shape: plumb the asset-lock outpoint into the controller after broadcast and scope the query by it.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/PendingPlatformTopUpsList.swift (line 45)

Verified at 3ea2f3a (lines 45-58 unchanged; the compactMap closure body unconditionally returns nil). orphans = resumableLocks(excludingControllerOutpoints: Set(inFlight.compactMap { _ in nil })) — the exclusion set is always empty by construction (the inline comment acknowledges this and notes the plumbing is here for a future tweak). The SwiftData status filter (statusRaw ∈ [1,3]) excludes Consumed locks, but an in-flight controller whose asset lock has just broadcast sits in status 2/3 long enough to render in the orphan list while its driving controller is concurrently in the in-flight list. Tapping Resume opens TopUpPlatformAddressView in resume mode against the same outpoint; the user can pick a different recipient, and the coordinator's single-flight gate (keyed on (walletId, platformAccountIndex, recipientHash)) doesn't catch the duplicate because the second submission keys differently. Bounded (Platform deterministically rejects the duplicate ST) but the user pays a full FFI round-trip on a guaranteed-to-fail submission. Same fix path as the progress-view finding: have the controller expose its asset-lock outpoint once broadcast and feed it into the exclusion set.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/TopUpPlatformAddressView.swift (line 717)

Verified at 3ea2f3a (default branch of switch newRows.count unchanged). When two address-top-up flows resolve Consumed in the same .onChange(of: controller?.phase) window, both controllers see newRows.count > 1 and both refuse to stamp. The accompanying doc comment claims controllers will retry on their next phase tick, but .completed is the terminal phase of AddressTopUpController.phase; the controller does not keep ticking after it lands there, and .onChange(of: controller?.phase) fires once per transition into .completed. If both controllers' .completed transitions land on the same MainActor turn (or close enough that both .onChange closures run before either back-fill saves), both back-fills see the same multi-element delta, both refuse, and neither row is stamped — permanently. UX-only (storage explorer shows '—' on both rows), not a correctness defect. Fix: in the multi-match branch, stamp the row matching the current controller's outpoint if the controller has one — same plumbing the progress-view and orphan-list findings want.

packages/rs-platform-wallet/src/wallet/platform_addresses/top_up.rs (line 129)

Verified at 3ea2f3a (no tests added to top_up.rs; file has no #[cfg(test)] module). submit_with_cl_height_retry has an explicit regression-pinning test in wallet/asset_lock/orchestration.rs, but the orchestrator composing preflight, funding resolution, IS→CL timeout fallback, IS-rejection fallback, retry submission, balance writeback, and asset-lock consume has no direct test. Behaviorally distinct branches that remain unpinned and cross the FFI boundary: (a) the IS-rejection path advancing tracked status InstantSendLocked → ChainLocked via advance_asset_lock_status + queue_asset_lock_changeset BEFORE the second submit_with_cl_height_retry — load-bearing for the truthful-status-on-double-failure invariant Swift's resume UI consumes; (b) the empty-address_infos post-condition returning PlatformWalletError::AddressSync(...) instead of consuming the asset lock — this error variant crosses the FFI boundary to Swift; (c) the split warn/error logging on consume_asset_lock failure (304-322); (d) the per-recipient skip-and-continue path in write_address_balances_changeset. A targeted #[tokio::test(start_paused = true)] set would pin the orchestration shape. PR description still marks end-to-end testnet validation as pending.

packages/rs-platform-wallet-ffi/src/platform_addresses/top_up.rs (line 222)

Verified at 3ea2f3a. The duplicate-collapse defect from prior finding #2 is fixed (lines 246-257 reject duplicates with ErrorInvalidParameter), but the null-pointer hardening sub-issue remains. The short-circuit at 230-232 returns early when addresses_count == 0 and the SAFETY doc scopes the non-null obligation to that case, closing the dominant UB hole (from_raw_parts(NULL, 0)). When addresses_count > 0 (line 234) the helper still calls std::slice::from_raw_parts(addresses, addresses_count) without verifying !addresses.is_null(). Both current FFI entry points gate with check_ptr!(addresses) before the call, so current call sites are sound. The helper is pub(super) and sits on a C ABI trust boundary; a future intra-module caller that omits check_ptr! for the non-zero case would reintroduce UB the optimizer is free to compile into a memory-safety bug on attacker-controlled FFI input. The deletion of fund_from_asset_lock.rs makes this helper the sole FFI decode path for address-fund recipients. Sibling decoders in platform_address_types.rs defensively null-check internally — aligning here removes a sharp edge from a security boundary at zero runtime cost.

packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/ManagedPlatformAddressWallet.swift (line 594)

topUpFromCorePreflight only validates recipient count and 20-byte hashes, but both top-up entry points marshal TopUpRecipient.addressType straight into PlatformAddressFFI at lines 446-451 and 548-553. On the Rust side, TryFrom<PlatformAddressFFI> accepts only address_type == 0, and validate_recipient_addresses accepts only PlatformAddress::P2pkh. A non-zero type therefore passes the documented Swift fail-fast preflight, crosses the FFI boundary, and fails later as a Rust invalid-parameter error. That splits the boundary contract across languages and defeats the purpose of the synchronous preflight.

for r in recipients {
    guard r.addressType == 0 else {
        throw PlatformWalletError.invalidParameter(
            "TopUpRecipient.addressType currently supports only 0 (P2PKH); got \(r.addressType)"
        )
    }
    guard r.hash.count == 20 else {
        throw PlatformWalletError.invalidParameter(
            "TopUpRecipient.hash must be exactly 20 bytes (got \(r.hash.count))"
        )
    }
}

packages/rs-platform-wallet/src/wallet/platform_addresses/top_up.rs (line 283)

After a successful proof-verified submit, this path updates the in-memory account via write_address_balances_changeset(...), optionally consumes the tracked asset lock, and returns Ok(cs), but it never calls self.persister.store(cs.clone().into()). Sibling mutating flows such as packages/rs-platform-wallet/src/wallet/platform_addresses/transfer.rs and packages/rs-platform-wallet/src/wallet/platform_addresses/sync.rs do persist their balance changes. The Swift FFI layer only decodes the returned PlatformAddressChangeSetFFI into [UpdatedBalance]; it does not write those balances back to the Rust persister. A restart after Platform accepted the top-up but before a later sync will therefore reload stale platform-address balances from initialize_from_persisted, even though the asset lock may already be consumed.

packages/rs-platform-wallet/src/wallet/platform_addresses/top_up.rs (line 273)

The new guard rejects only the completely empty proof case. After that, the function always writes balances, consumes the tracked asset lock, and returns success. The SDK already enforces that the proof contains the expected address keys, but AddressInfos still allows None values for those keys, and write_address_balances_changeset explicitly logs-and-skips None entries at lines 356-367 instead of failing. That means a proof shape the code itself describes as a contract violation can still result in a partial changeset while the funding lock is permanently consumed. The post-condition needs to reject any recipient whose proof entry is missing usable AddressInfo before cleanup runs.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/PendingPlatformTopUpsList.swift (line 45)

resumableLocks(excludingControllerOutpoints:) is called with Set(inFlight.compactMap { _ in nil }), so the exclusion set is always empty. The comment confirms controllers do not currently expose the outpoint they are driving. As written, an asset lock that is already being processed by an in-flight controller can still appear in the resumable list at the same time, and the user can open a second resume flow against the same outpoint. The coordinator only single-flights on (walletId, platformAccountIndex, recipientHash), so choosing a different recipient hash bypasses that protection even though Platform will later reject the duplicate consume.

packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/TopUpPlatformAddressView.swift (line 717)

backfillRecipientOnConsumedLock() runs only when activeController?.phase changes to .completed at lines 137-147. In the snapshot-delta branch, any newRows.count > 1 path logs and returns without writing recipientPlatformAddressHash or recipientPlatformAddressType. When two top-ups complete in the same visibility window, both controllers can observe the same multi-match set, both refuse to stamp, and neither controller gets another phase transition that would retry the backfill. The result is a permanent metadata hole in storage even though each controller already knows its own recipient identity.

packages/rs-platform-wallet/src/wallet/platform_addresses/top_up.rs (line 273)

The post-submit guard at 273-281 only rejects the wholly-empty address_infos.is_empty() case, but write_address_balances_changeset at 351-368 also treats per-entry None as a protocol-contract violation, logs it, and skips the balance write while continuing the loop. Control then falls through to consume_asset_lock at line 304 unconditionally, so a multi-recipient top-up whose proof attests some recipients but not others still burns the asset lock while silently dropping the unfunded recipients, and the row is marked terminal Consumed so the Resume path will not pick it up. The function's own comment at 265-272 already calls this case a 'DAPI / proof-verifier contract violation, NOT a successful zero-credit funding' — the empty-map check should be extended to reject any-None as well so the lock stays in non-Consumed status and the operator can re-drive. Today's only in-tree caller is single-recipient so this is latent, but the function signature accepts arbitrary multi-recipient maps and asset locks represent non-refundable L1 funds.

packages/rs-platform-wallet/src/wallet/platform_addresses/top_up.rs (line 283)

After a verified submit, this path calls write_address_balances_changeset(...) to mutate the in-memory ManagedPlatformAccount, optionally consumes the tracked asset lock, and returns Ok(cs) — but it never sends cs through self.persister.store(cs.clone().into()). Sibling mutating address flows do persist their returned changeset (platform_addresses/transfer.rs:155-158 and platform_addresses/sync.rs:79-84). As coded, the credited balance lives only in memory until the next BLAST sync writes a row over the top; on app restart/reload before that, initialize_from_persisted will seed account.address_credit_balance from the stale pre-top-up persisted row and overwrite the freshly credited in-memory state — causing later auto_select_inputs to under-budget inputs and producing protocol-level rejections until the next sync. Either persist the changeset here matching the sibling pattern, or document the explicit guarantee that another sync call will run before any reload.

packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/ManagedPlatformAddressWallet.swift (line 594)

topUpFromCorePreflight validates only recipients.isEmpty, the noneCount == 1 invariant, and r.hash.count == 20. It never inspects TopUpRecipient.addressType, even though the field is documented as 0 = P2PKH, 1 = P2SH. Mirrors the Rust-side PlatformAddress discriminant. Both topUpFromCore and resumeTopUpFromAssetLock marshal r.addressType straight into PlatformAddressFFI(address_type: r.addressType, ...). On the Rust side, impl TryFrom<PlatformAddressFFI> for PlatformAddress in packages/rs-platform-wallet-ffi/src/platform_address_types.rs:37-45 accepts only address_type == 0 and returns Err("Unsupported address type") for anything else (including the 1 = P2SH discriminant the From direction will emit). A caller following the documented Swift API and passing addressType: 1 clears the preflight, pays for the Task detach and signer pinning, and only then receives a generic FFI error — defeating the preflight's stated purpose of producing a synchronous, type-specific Swift error. Either tighten the preflight to require r.addressType == 0 (lower-risk, matches the rest of the funding pipeline which assumes P2PKH for the asset-lock recipient hash) or extend the Rust TryFrom to accept 1 => P2sh.